Re: [PATCH 5/5] build.sh: Force 'yes' for apt

[Alexander Smirnov <asmirnov@ilbers.de>]

On 02/05/2018 02:52 PM, Jan Kiszka wrote:
> On 2018-02-05 10:59, Alexander Smirnov wrote:
>> Sometimes the following error occurs with custom repo:
>>
>> After this operation, 84.0 kB of additional disk space will be used.
>> WARNING: The following packages cannot be authenticated!
>>    libhello libhello-dev
>> E: There are problems and -y was used without --force-yes
>>
>> This patch adds '--force-yes' option to be sure that no dialog will occur.
>>
>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>> ---
>>   meta/recipes-devtools/buildchroot/files/build.sh | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-devtools/buildchroot/files/build.sh b/meta/recipes-devtools/buildchroot/files/build.sh
>> index b63a27e..06df1da 100644
>> --- a/meta/recipes-devtools/buildchroot/files/build.sh
>> +++ b/meta/recipes-devtools/buildchroot/files/build.sh
>> @@ -21,7 +21,7 @@ cd $1
>>   # Notes:
>>   #   1) everything before the -y switch is unchanged from the defaults
>>   #   2) we add -y to go non-interactive
>> -install_cmd="apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -y"
>> +install_cmd="apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -y --force-yes"
>>   
>>   # Install all build deps
>>   mk-build-deps -t "${install_cmd}" -i -r debian/control
>>
> 
> For this, I'm in favor of Cedric's patch because it has a more targeted
> solution for the problem and explains it clearly this way.
> 

Tested this series with his patch, works good - so no objection from me. 
So my one dropped and this will be applied.

> However, we likely have to tune this further in the future:
> 
> - avoid that installation from all repos can be unauthenticated
> - deal with key installation for 3rd-party repos, likely carrying the
>    keys in a meta layer
> 
> Eventually, we will also have to deal with reproducing builds from repos
> that have expired keys.
> 

The issue for me here is traceability for such problems where we disable 
interactive interface. To get error message about unsigned repo I had to 
run 'apt-get' manually inside buildchroot, bitbake do_build.log was 
empty. :-( It would be nice to have some traceability without manual 
attempts to reproduce the issue.

P.S. I just share my thoughts, no questions to this patch.

Alex