On Wed, Jun 03, 2020 at 11:37:21 +0200, Erik Skultety wrote: > On Wed, Jun 03, 2020 at 11:29:36AM +0200, Peter Krempa wrote: > > On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote: > > > On 6/3/20 10:40 AM, Peter Krempa wrote: > > > > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote: > > > > > On 6/3/20 9:31 AM, Peter Krempa wrote: [...] > > Well. They are built on fedora, but certainly not taken from fedora. > > It's built from git. > > > > > Maybe we can document configure arguments for QEMU so that it is > > > reproducible. > > > > While I agree that we should do that to take one of the moving parts out > > of the equation we still can't do anything about the machine dependance > > of the output. Specifically it contains all cpu flags so it really can't > > be re-generated reproducibly on a box with even a slightly different > > cpu. > > > > Ideally we'd build it with the fedora spec-file, but I got lazy and I'm > > usually just re-running configure from my history in this case. > > > > My only idea how to provide stable output is to create a job on a box > > which will periodically re-build qemu and fetch the capabilities and > > publish them somewhere so that others could grab those and refresh the > > caps themselves, but I can't really think of a way how to enable others > > do it on their machine whithout messing up the CPU. > > You beat me in the response time wrt reply :). Hmm, how about we add this as a > job to lcitool which controls how virt-install is spawned, that way + an Ansible > playbook you always get a reproducible environment? I don't think that's a particularly worthwhile idea. It would have to run fully emulated to shield from cpu differences which would make it super slow. In such case I'll rather periodically or on request update it myself rather than deal with something which takes ages.
