<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Aug 2019 at 15:25, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 6 Aug 2019, Antony Antony wrote:<br>
<br>
> My guess is that 474b105c2c is trying to pin some packages such as kernel<br>
> or/and strongswan.<br>
> If that is the case I would prefer /etc/dnf/dnf.conf way of excluding than<br>
> $(KVM_PACKAGE_UPGRADE) alone, otherwise  dnf update and daily install would<br>
> conflict.<br>
<br>
We should not pin strongswan or the kernel? Now that we are on "bleeding<br>
edge", I think we can take the bleeding when it happens.<br>
<br></blockquote><div><br></div><div>Having just tried to go through old releases and reproduce test results, I'm forced to conclude that agreeing to unpinning strongswan and the kernel was a stupid foolish mistake.</div><div><br></div><div>For instance, I can't even reproduce f28's results (yet alone anything earlier).  This is because a kernel that didn't even exist at the time f28 was released gets installed on the test VMs.  Instead, for the test VMs we need to ensure that what we tested the release against an always (within a few limitations) be reproduced.</div><div><br></div><div>Andrew</div><div><br></div><br></div></div>