search for: upsreams

...as required to stay on an LTS. Also to do every second >> point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term >> than upstream, BUT we have supported code from upstream. >> >> So, the goal is to use supported code for the longest amount of time the >> upsreams support them. For xenproject.org .. they support the two >> newest releases. For kernel.org, they do a new kernel LTS about every 2 >> years. >> >> We don't have 5000 engineers to maintain community SIGs like they >> maintain the distro. We have to have supporte...

...use an upstream LTS kernel and update those as required to stay on an LTS. Also to do every second point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term than upstream, BUT we have supported code from upstream. So, the goal is to use supported code for the longest amount of time the upsreams support them. For xenproject.org .. they support the two newest releases. For kernel.org, they do a new kernel LTS about every 2 years. We don't have 5000 engineers to maintain community SIGs like they maintain the distro. We have to have supported code from upstream projects. On 01/21/201...

There are basically three issues we''re waiting to sort out (see below for more info): * XSA-55 * cpu hotplug in qemu-upsream * The MMIO hole issue Unfortuantely, there is considerable uncertainty about how long it will take for each of those to complete. We''re hoping to be able to release maybe on the 19th, This information will be mirrored on the Xen 4.3 Roadmap wiki page:

...> update those as required to stay on an LTS. Also to do every second > point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term > than upstream, BUT we have supported code from upstream. > > So, the goal is to use supported code for the longest amount of time the > upsreams support them. For xenproject.org .. they support the two > newest releases. For kernel.org, they do a new kernel LTS about every 2 > years. > > We don't have 5000 engineers to maintain community SIGs like they > maintain the distro. We have to have supported code from upstrea...

>> 2. Is there a page like Ubuntu's CVE Tracker site where it shows the >> CVE, the package name, and the status > > Red Hat (CentOS's upsream) posts advisories for these sorts of things: > > https://access.redhat.com/errata/RHSA-2020:2969 > > This is the security advisory for this package. Yeah, I found this page cause harbor even links these, I apparently

> There is a bug with nss_ldap and bash32 ... I created a new RPM for the > nss_ldap that is currently in our testing repo. Johnny, I was wondering if that RPM includes the security fixes detailed in https://rhn.redhat.com/errata/RHSA-2008-0389.html Thanks in advance, M

I have a docker image based off centos:7 with java-11-openjdk-devel. It appears that the current java-11-openjdk-devel available in the CentOS 7 Yum repo is 1:11.0.7.10-4.el7_8 11.0.7 is reported to have some high vulnerabilities RHSA-2020:2969 that are fixed in 11.0.8, but 11.0.8 is not available for CentOS 7. 1. Is there a 11.0.8 update for java-11-openjdk-devel available for CentOS 7? 2. Is

Hi list, Since the upgrade to 5.2, when I log into my server with a ldap account I have these 2 errors messages: -bash: [: =: unary operator expected -bash: [: -le: unary operator expected After investigation, the trouble come from two scripts in /etc/profile.d: /etc/profile.d/krb5-workstation.sh /etc/profile.d/vim.sh The problem is with the test where the command "id" is involved,

...d > update those as required to stay on an LTS. Also to do every second > point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term > than upstream, BUT we have supported code from upstream. > > So, the goal is to use supported code for the longest amount of time the > upsreams support them. For xenproject.org .. they support the two > newest releases. For kernel.org, they do a new kernel LTS about every 2 > years. > > We don't have 5000 engineers to maintain community SIGs like they > maintain the distro. We have to have supported code from upstream...

One thing that we are often blamed for is trying to stifle conversations and to discourage people from commenting / contributing / encouraging conversations. And that cant be further from the truth, really. We are all pro-community ( and when I say we, I mean everyone - including the contributors, developers, admins, users, abusers and hey upstream too ). However, one thing that does get in

?My .02 is to stay the course. ?As a server admin, I want to be able to type things like: yum upgrade php ????not yum upgrade php55-epel-rpmforge-fancy-package Having to remember all the idiosyncrasies of a system is what causes some type of major failure in the future whenever (1) you forget something or (2) someone else has to pick up the box to adminster. -- ?Craig Thompson,