Dear list,   I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it.   In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now.   I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch.   If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].

Dear list, I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it. In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now. I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch. If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].

On 09.02.2016 13:52, Daniel P. Berrange wrote: > On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote: >> Dear list, >> >> I've noticed a failed build on CentOS-6 after some commits. Problem was >> that old gcc is not wise enough and produces a false positive. I've >> proposed a patch for that [1] but honestly, neither am I - like Peter - >> very fond of this approach. We should not try to fix a good code because >> of some spurious warnings. Moreover if they happen on a system that is >> considered stable and thus nobody should run recent libvirt on it. >> >> In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now. >> >> I'm starting this thread so that the decision and discussion is clear >> and not buried under discussion to the patch. >> >> If we happen to stop caring we probably should stop our CentOS-6 build >> in jenkins too [2]. > > IMHO it is well premature to stop caring about RHEL-6. We only just > dropped support for RHEL-5, but RHEL-6 is very much still a widely > used platform and will continue to be so for a good while yet. Sure, but I'm not talking about downstream support rather than upstream one. Or are you saying that nor upstream should drop RHEL-6?

On Tue, Feb 09, 2016 at 12:59:45 +0000, Daniel Berrange wrote: > On Tue, Feb 09, 2016 at 01:56:19PM +0100, Michal Privoznik wrote: > > On 09.02.2016 13:52, Daniel P. Berrange wrote: > > > On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote: ... > > > IMHO it is well premature to stop caring about RHEL-6. We only just > > > dropped support for RHEL-5, but RHEL-6 is very much still a widely > > > used platform and will continue to be so for a good while yet. > > > > Sure, but I'm not talking about downstream support rather than upstream > > one. Or are you saying that nor upstream should drop RHEL-6? > > I'm talking about upstream too. Libvirt is *not* about only supporting the > latest cutting edge distros. We aim to support a broad range of distros > that are currently widely in use. RHEL-6 most certainly falls under that > umbrella, and upstream libvirt must *not* drop it as a targetted platform. The qemu in rhel6 has diverged so much from it's original code base that libvirt is carrying hacks to make it work: commit ff88cd590572277f10ecee4ebb1174d9b70fc0d7 Author: Eric Blake <eblake(a)redhat.com&gt; Date: Wed Jan 25 21:33:21 2012 -0700 qemu: support qmp on RHEL/CentOS qemu I'm getting tired of remembering to backport RHEL-specific patches when building upstream libvirt on RHEL 6.x or CentOS. All the affected versions of RHEL qemu-kvm have backported enough patches to a) make JSON useful, and b) modify the -help text to mention libvirt as the preferred interface; which means this string in the help output is a reliable indicator that we can outsmart a strict version check, even when upstream qemu 0.12 lacked the needed features. This code looks specifically for the string "libvirt" which was added by the downstream version. The upstream libvirt doesn't carry a few downstream patches that make certain features work though. With the above code we are able to run with the qemu, but I'd not really want to call it that we support it. We merely put it on life support so that it works. Additionally you don't really gain much with just using new libvirt, and when you want to compile new qemu you might as well as use a completely new system as well. Using it on Centos6 would not really add any benefit in this regard. The above is to point out that users of Centos 6 usually won't compile libvirt and qemu from sources since they want to enjoy benefits of a stable platform with tested software. Sticking upstream versions on top of that defies the purpose.

On Tue, 2016-02-09 at 14:18 +0000, Daniel P. Berrange wrote: > > The above is to point out that users of Centos 6 usually won't compile > > libvirt and qemu from sources since they want to enjoy benefits of a > > stable platform with tested software. Sticking upstream versions on top > > of that defies the purpose. >  > NB, RHEL is not the only distro we target - when I say we should target > RHEL-6 as the oldest platform, I use that mostly as an example of the > approximate vintage. I would consider any still supported Debian version > that is the same age as RHEL-6 to be a valid platform too, likeise for > Ubuntu LTS releases or SLES. At least some of those will using fairly > vanilla QEMU version without feature backports. Do you mean SLES 11, RHEL 6 or Ubuntu 12.04 are likely to get the latest upstream libvirt release as a vendor update?

I tend to agree with Peter when he says that people stick with older versions of software because they have a working setup and don't want to risk it breaking, and replacing vendor-provided system components with manually compiled upstream releases kinda goes in the opposite direction :) I would definitely never have risked anything like that in my previous life as a system administrator.

Dear list, I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive.

If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].

2: https://ci.centos.org/view/libvirt-project/job/libvirt-daemon-build/syste...