From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6691586504498610176 X-Received: by 2002:ac2:494f:: with SMTP id o15mr2894148lfi.84.1559553244145; Mon, 03 Jun 2019 02:14:04 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:6b10:: with SMTP id d16ls171953lfa.10.gmail; Mon, 03 Jun 2019 02:14:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqxtSkvHAOihrsPh3d/drv/Hg9wFXXdwX6wAveYadvP+UNOI83I42kxwoC5Fo/0whGcRPaIX X-Received: by 2002:a19:9156:: with SMTP id y22mr7378161lfj.43.1559553243700; Mon, 03 Jun 2019 02:14:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559553243; cv=none; d=google.com; s=arc-20160816; b=QsEOPktS5X/hAFurLgcQUfttY5miFiXpYfhxJU6QBJSa7jQtFiieryCVOhiTsclyOv bJpDe28z8L7wZZnSA7Q1ftQwxJJSpRt8sNWwPK2YzoWSmPGHpnR8B7ez4UIhi4ttqYHi 8sM1Hs6nQOYqUpsoqyipbniBLcJTU0U/NLdfAxoC0TsqU5u7nx74v7wioiDVAdpBF9dq LOb+gulau1ShkkjV1UjS7XzcadjdXIdiOqCucyK/hOGWAfaAE0aiCHcq/8nTqwbzN4ou imi7ummA7sakLoozuZ7sZxeeFfL/A8zXXwdmGqJ3vGvnqhi6/Cs/FoRQnFOGR49BKxsU IUDQ== 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=7lc6yze4U+dQu1a1LDxnkZSUyqinyPYzQCpBpfhLj34=; b=AbY1yD2JGHLhXHN1B4CycFJtin/gcrgG0uIr2H45hxqC7EKh9bG5qOASkBXwzVN1hj ZppG/PN3sevE6GNEaCECLS0ZzUoswdEid8QuNUUIfBzcJsRF3N7yd3eMKhcU8SeZksSz zZTuhZfuyIpzCiJT5oolrxiUUE5RBJVH4KLNXKeF4PN74H4nViSCkwjzBM6dGDuAnWAe 5QfBacWUse902pN8N9JzSV6xxHdeeJZvRYNsz2kvb3Zx+xnxxnjHobFsUYxq/qrJNnZW z2esA2lnC/45ZOcja7Gi+u3+5y7JHYAimgm52j4+CliLD4zOKQW2l/ifQwrBebHYN5ZM mwJw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id n4si488064lfl.3.2019.06.03.02.14.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 02:14:03 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x539E2pW030697 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 3 Jun 2019 11:14:02 +0200 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x539E19s029137; Mon, 3 Jun 2019 11:14:02 +0200 Subject: Re: [PATCH v4 4/8] meta/classes: add image-account-extension class To: Jan Kiszka , isar-users@googlegroups.com Cc: Claudius Heine References: <20190523145521.23050-1-claudius.heine.ext@siemens.com> <20190523145521.23050-5-claudius.heine.ext@siemens.com> From: Claudius Heine Message-ID: <3413a950-6431-adca-a05b-d76718c19f1d@siemens.com> Date: Mon, 3 Jun 2019 11:14:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: w1DerLx+KHLE Hi Jan, On 31/05/2019 09.29, Jan Kiszka wrote: [...] >> +inherit image-account-extension >>   # Extra space for rootfs in MB >>   ROOTFS_EXTRA ?= "64" >> > > Seems like we are not rebuilding the affected recipes when variables > change. That's at least true for the root password I just played with. > Fixable? Interesting. My intention was to implement it in a way to avoid this issue, but I guess that needs some further investigation then. Just to make clear how I thought it worked: This line should add the all bitbake functions in `ROOTFS_CONFIGURE_COMMAND` and `ROOTFS_INSTALL_COMMAND` to the `vardeps` flag. Because bitbake functions are variables as well, that should mean that `do_rootfs_install` depends on the content of those functions, including all expanded bitbake variables (at least so I thought): meta/classes/rootfs.bbclass: do_rootfs_install[vardeps] = "${ROOTFS_CONFIGURE_COMMAND} ${ROOTFS_INSTALL_COMMAND}" It would be good to investigate why that didn't work. A simple fix would be to add `IMAGE_ACCOUNTS_USERS` and `IMAGE_ACCOUNTS_GROUPS` to that flag as well. But it would be good to investigate first why that approach did not work and possible fix that, because that mechanism is used elsewhere as well. regards, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de