[yocto] possible bug with dpkg-native with sstate-cache

[Anders Oleson]

On Wed, Dec 14, 2016 at 2:01 AM, Jussi Kukkonen
<jussi.kukkonen at intel.com> wrote:
> On 14 December 2016 at 06:59, Anders Oleson <anders at openpuma.org> wrote:
>>
>> I have found what I think is a sneaky nasty bug when using package_deb
>> with
>> SSTATE_MIRRORS on RPM based build hosts. Below is a short description of
>> what
>> I found and our workaround. A patch that adds a patch that is applied to
>> the
>> packager that packages the real packager.  To avoid this sneaking failure
>> mode
>> when building without building when using the cache (its all so very
>> meta, btw.).
>>
>> Don't ask how we found this; it wasn't pretty.
>>
>> Note: the fix approach below actually patches dpkg on the target too,
>> but I do not
>> know how to easily make the patch only apply to dpkg-native and not also
>> dpkg.
>> But in this case it should be fine anyhow; there is no reason that dpkg on
>> the
>> target should not behave this way too. I have checked the upstream and the
>> lines in question have never been touched - it is possible they may want
>> to
>> eventually upstream this too (???).
>
>
> I have to point out that the upstream developers are usually not going to
> come to us looking for patches :) If we want patches upstreamed we have to
> go to them and in fact there is a bit of process to to track this, see
> below.

Yes, I'm more or less thinking out loud whether it would be something
they care about.
I'm not sure they would, but I may ask and see. There's a minor issue
in that the
error message would disappear in case of a real misconfiguration, but
this morning I
see that on my Ubuntu box that the directory is empty anyhow.

>
>> For future knowledge, is there an easy way to have a SRC_URI list that is
>> different for dpkg-native than for dpkg?
>
>
> I think this is actually already used in dpkg recipe:
>     SRC_URI_append_class-native = "..."
> but as you said this doesn't seem required in this case.
>

OK, wasn't sure if this was a good idea and I missed the example. So
that all makes sense.
By the time I formulated the question I was 1/2 way there...

>> Also, this is my first post to the group, so apologies if this is not the
>> right place or way to upload a potential patch; set me straight if so.
>
>
> Thanks and no problem: openembedded-core at lists.openembedded.org would be the
> correct place for meta/ patches. Please take a look at
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#how-to-submit-a-change
>     http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>
> Some specific things you may want to look at:
> * Send the commit as part of an email, not as attachment (git "send-email"
>   and/or "create-pull-request/send-pull-request" script are good tools)
> * Signed-off-by tag on both the commit and in any patch files in it
> * Upstream-Status tag in any patch files in the commit
>
> Thanks,
>  Jussi

Will do. It may take a bit to process all that, but I will.