http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/ is failing since yesterday on Error: Problem 1: conflicting requests - nothing provides ovirt-vmconsole >= 1.0.0-0 needed by vdsm-4.20.11-7.git4a7f18434.fc27.x86_64 after already passing in the past. Can this be solved on ovirt-vmconsole side, or should we disable fc27 (again)?

On Fri, Jan 5, 2018 at 10:20 AM, Francesco Romani <fromani(a)redhat.com&gt; wrote: > On 01/05/2018 08:16 AM, Dan Kenigsberg wrote: >> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/ >> is failing since yesterday on >> >> Error: >> Problem 1: conflicting requests >> - nothing provides ovirt-vmconsole >= 1.0.0-0 needed by >> vdsm-4.20.11-7.git4a7f18434.fc27.x86_64 >> >> after already passing in the past. >> >> Can this be solved on ovirt-vmconsole side, or should we disable fc27 (again)? > > Speaking as maintainer of ovirt-console, it is a good chance to review > what's the status of ovirt-vmconsole, and how we can improve things for > the current state and for the future. > > ovirt-vmconsole is pretty stable codewise and featurewise (and, I'd say, > bugwise), in the last 12+ months I hardly gathered material for another > minor release (would be 1.0.5), which > is not planned yet, as further proof that the codebase is stable. > > Most of time, the only thing needed is to ship the existing packages for > a new distro release. It seldom may be needed a simple rebuild. > > I must say I'm not aware of how the current issue was solved for fc26, > IIRC some manual intervation was applied along the lines above. > Can we automate this step somehow? Barak and Sandro can surely help with regards to fc27, and may have ideas on how to automate this to future releases.

On 07.01.2018 11:11, Barak Korren wrote: [...] > > I looked into what happened there. > > It seems that Sandro added fc27 jobs a few weeks ago ago, and he also > took the time to trigger the jobs manually to get an FC27 build. > > The issue is that this is not enough to get a build to properly go > through the automated test and release processes, > > The CI system is build to respond on code changes. For most projects > that is enough because new patches are merged frequently and as new > jobs are added, patches show up soon after and trigger them. > > The root cause for this issue is that the set of platforms a project > targets is currently maintained separately from the project's source > code, so adding a new target platform is not always manifest in a code > change to the project. We're working on resolving this by making the > set of target platform be specified in the project's own source code. > This would eventually mean that adding a new target platfrom will > always require a patch to the project. > > For now, I've emulated a merge event on the latest patch to > ovirt-vmconsole. This will cause the fc27 build (as well as others) to > get recreated and pushed through the change-queue. > I think we face a similar problem for the s390x builds of ovirt-host. Looks like the last changes to ovirt-host have been done before the s390x fc27 jobs have been merged, so there are no s390x RPMS in the repository. Could you or someone else trigger a full ovirt-host build?