When building OpenBMC . . . ?
Bills, Jason M
jason.m.bills at linux.intel.com
Thu Sep 3 07:39:36 AEST 2020
On 9/2/2020 12:50 PM, Patrick Voelker wrote:
>
>> On Wed, Sep 02, 2020 at 06:50:01PM +0000, Patrick Voelker wrote:
>>> I'm giving the first option below a try. I've defined an alternative variant
>> and have included the meta-facebook/meta-tiogapass layer in my build.
>>>
>>> One problem I'm running into is that meta-tiogapass includes a
>> rsyslog*.bbappend and one of the other layers I'm using also has a similar
>> rsyslog*.bbappend.
>>>
>>> Each do an append to do_install() and each one tries to remove
>> ${D}${sysconfdir}/rsyslog.d/imjournal.conf. Of course that file can only be
>> removed once so the build fails.
>>>
>>> My question now, is what's the best way to work around this? I don't need
>> rsyslog from meta-tiogapass, just the machine specifics.
>>
>> If this is a common pattern, we should try to contribute it upstream to Yocto
>> as a PACKAGECONFIG option. Then we can add to the PACKAGECONFIG in
>> the bbappend (you can do that as many times as you want).
>>
>> If we don't think Yocto would accept it, or they reject it, but it is still
>> something we're seeing often in our systems we can similarly add it as a
>> common bbappend in meta-phosphor (ideally triggered by a
>> PACKAGECONFIG).
>
> Thanks for the response but I'm having a hard time connecting the dots.
>
> My understanding of PACKAGECONFIG is that it's a way to provide build options for individual packages. In this case, what PACKAGECONFIG option would we be contributing?
>
> Is there a way now for me to force bitbake to ignore (or not use) rsyslog*.bbappend in meta-tiogapass from another layer?
>
> The two appends that are conflicting are:
> meta-facebook/meta-tiogapass/recipes-extended/rsyslog/rsyslog_%.bbappend
> meta-intel/meta-common/recipes-extended/rsyslog/rsyslog_%.bbappend
I hit a similar issue when moving this recipe out of my downstream
build. I was able to resolve it by putting this change in my downstream
version:
diff --git a/meta-common/recipes-extended/rsyslog/rsyslog_%.bbappend
b/meta-common/recipes-extended/rsyslog/rsyslog_%.bbappend
index 7e282804..ef670451 100644
--- a/meta-common/recipes-extended/rsyslog/rsyslog_%.bbappend
+++ b/meta-common/recipes-extended/rsyslog/rsyslog_%.bbappend
@@ -17,7 +17,7 @@ do_install_append() {
install -d ${D}${systemd_system_unitdir}/rsyslog.service.d
install -m 0644 ${WORKDIR}/rsyslog-override.conf \
${D}${systemd_system_unitdir}/rsyslog.service.d/rsyslog-override.conf
- rm ${D}${sysconfdir}/rsyslog.d/imjournal.conf
+ rm -f ${D}${sysconfdir}/rsyslog.d/imjournal.conf
}
SYSTEMD_SERVICE_${PN} += " rotate-event-logs.service
rotate-event-logs.timer"
We can apply a similar change to one or both of these upstream recipes.
Or, is this a candidate for meta-phosphor?
>
> Can I choose one over the other instead of having them build upon eachother?
>
More information about the openbmc
mailing list