Re: [CentOS] Blog article about the state of CentOS
On Mon, Jun 22, 2020 at 6:43 AM Peter wrote: > On 22/06/20 10:13 am, Stephen John Smoogen wrote: > > There are 2 sets of work. > > 1. There is the work on the tools which were slapped together as an > > emergency from parts before 8.0. Those mbboxx tools are getting a > > rewrite and upgrade currently by the CPE team to make them more useful > > in the future. Stream only helps in that it is the excuse for that > > work to be done versus it molding and falling apart right after every > > 8.x release comes out. > > I didn't know that a rewrite is still needed on the current tool set and > granted Stream can help with this, but I hardly think that it's > necessary and the tool set can always be tested against the current > release (8.2) from git. > > > 2. There is the work that happens because various things are rebased > > and you need to figure out the HTF you get from build A to build A+1 > > by rebuilding N packages. That is work that Stream should help on > > because this is then knowledge is being done in stream before hand. If > > you know that package A went to A+1 then to A+2 and then back to A+1 > > but you learned how to do the second A+1 from a flag you used with > > A+2, then the amount of time reinventing the wheel is shortened. > > This I do realize and it's the one exception I considered where Stream > might come in handy, but not handy enough to justify its existence, imo. > Usually in a new point release there might be a small handful of > packages that need re-basing, out of those the number of packages that > would need to have the spec file tweaked to build them would be minimal > (at a complete guess three or less) and out of those the number that > would require a change to the tool set would likely average out to be > less than one per point release. In a worst-case scenario it might save > a day or two on a particularly nasty point release, and this would > easily be recouped in the amount of time it would save if the CentOS > team did not have to maintain Stream at all. > > Now these are just semi-educated guesses and I don't have the experience > to justify this so I'm happy to consider real numbers that prove me wrong. > > > > Hi, Now I have RHEL 8 installed for my test machine and some test Virtual Machines. I then subscribed to the RHSA-announce mailing list. Now I wonder why a particular package has not been released for CentOS 8 while it has been some time on RHEL OS and mailing list. With CentOS 7, I had no RHEL developer access, so I never wondered why a particular update has not been released CentOS 7 I just used CentOS 7 and was happy. Is this a valid reason for my impatience? - Lee ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 184, Issue 9
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CEBA-2020:2656 CentOS 7 net-snmp BugFix Update (Johnny Hughes)
2. CEBA-2020:2658 CentOS 7 resource-agents BugFixUpdate
(Johnny Hughes)
3. CEBA-2020:2660 CentOS 7 rsyslog BugFix Update (Johnny Hughes)
4. CEBA-2020:2657 CentOS 7 fence-agents BugFix Update (Johnny Hughes)
5. CEBA-2020:2666 CentOS 7 ca-certificates BugFixUpdate
(Johnny Hughes)
6. CEBA-2020:2655 CentOS 7 ncompress BugFix Update (Johnny Hughes)
7. CESA-2020:2642 Important CentOS 7 unbound Security Update
(Johnny Hughes)
8. CEBA-2020:2654 CentOS 7 cloud-init BugFix Update (Johnny Hughes)
9. CESA-2020:2663 Moderate CentOS 7 ntp Security Update
(Johnny Hughes)
10. CESA-2020:2664 Important CentOS 7 kernel Security Update
(Johnny Hughes)
--
Message: 1
Date: Tue, 23 Jun 2020 19:39:03 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2020:2656 CentOS 7 net-snmp BugFix
Update
Message-ID: <20200623193903.ga27...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2020:2656
Upstream details at : https://access.redhat.com/errata/RHBA-2020:2656
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
5c0bf0073f01c726782c0de15f56dc6844dc45bcbb7dccd0d56f3b1cc189ea7c
net-snmp-5.7.2-48.el7_8.1.x86_64.rpm
02c140eea0ec646667c3e5bcafb77e22831fb962346cc634afde9f8193f51a4c
net-snmp-agent-libs-5.7.2-48.el7_8.1.i686.rpm
e1fe727ad4c3c21e82a387cae425f4f1d0cb122ae453bdec77692ced05d12f1b
net-snmp-agent-libs-5.7.2-48.el7_8.1.x86_64.rpm
3dd62cedb4e8131f64241a53d8a079167481875ce1afd6ba0dc13a0d3d2f8fef
net-snmp-devel-5.7.2-48.el7_8.1.i686.rpm
6c75ffa234e81ec06467ae939b151eb7576c6a1d2ae9a084b685e429fcfe7a86
net-snmp-devel-5.7.2-48.el7_8.1.x86_64.rpm
f567f74cd647ab8385a5f4ee47caad26e275004f93156cb6ee10e1dd8199eee5
net-snmp-gui-5.7.2-48.el7_8.1.x86_64.rpm
78dff1bff4f5cd5a84f58fbb6d5b907fffad62b46e7103b5ab276585c68d3b4e
net-snmp-libs-5.7.2-48.el7_8.1.i686.rpm
40095b5d1251bdb075efc1332dbf0bc4d77878976ffd247ec8adfd60657148c9
net-snmp-libs-5.7.2-48.el7_8.1.x86_64.rpm
b504a4aa520d9a8c98e82ec1284decae0f19dc0eede9eea23ecdb8fa9f03dd4d
net-snmp-perl-5.7.2-48.el7_8.1.x86_64.rpm
f5d09527738f1d197493253a95db63232b9a0b6248055d53aa14c490204fb3e3
net-snmp-python-5.7.2-48.el7_8.1.x86_64.rpm
7855d4ed5e164c3f3cacb8e604a558f9c3134cba39080616aeb1a16549eb6ad4
net-snmp-sysvinit-5.7.2-48.el7_8.1.x86_64.rpm
aa67b6ad522a919688c63079a6fe2e1c702230fce8426445355e2bccaa6b5b4f
net-snmp-utils-5.7.2-48.el7_8.1.x86_64.rpm
Source:
626018542748f9a1f20521a00822d4ba53e8e79736609394215f28e706d6d178
net-snmp-5.7.2-48.el7_8.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 2
Date: Tue, 23 Jun 2020 19:39:20 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2020:2658 CentOS 7 resource-agents
BugFix Update
Message-ID: <20200623193920.ga27...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2020:2658
Upstream details at : https://access.redhat.com/errata/RHBA-2020:2658
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
7ede75337aeaab6df18ec2f375702708f5d528462ed5f0da66f588704fc87401
resource-agents-4.1.1-46.el7_8.2.x86_64.rpm
3bdcd8a256733768faf9fd06ed664b4c9cdb5e829048fb80b76300dba373a0ca
resource-agents-aliyun-4.1.1-46.el7_8.2.x86_64.rpm
e91dfb1257041eea3e8184beb85ce2ff6029c3fb85e344015dffbfcc88c353b6
resource-agents-gcp-4.1.1-46.el7_8.2.x86_64.rpm
Source:
92ae7a64b35be5e62b918cecd5291a55dc9b0ac43db60ab89580af03a1be11df
resource-agents-4.1.1-46.el7_8.2.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 3
Date: Tue, 23 Jun 2020 19:40:14 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2020:2660 CentOS 7 rsyslog BugFix
Update
Message-ID: <20200623194014.ga27...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2020:266
Re: [CentOS] Blog article about the state of CentOS
On 6/20/20 6:50 AM, Peter wrote:
On 20/06/20 3:50 am, Johnny Hughes wrote:
And EL8 is exponentially harder with an entirely new build system and
the requirement to build modules.
But it seems like every major release has had reasons to be
exponentially harder than the last. With 7 it was the shift to using
the git sources instead of the SRPMS that were previously provided by
Red Hat, thereby necessitating an entirely new build system, plus the
change to systemd and the introduction of a new point release
numbering scheme, not to mention the move to entirely new
infrastructure because of the change to Red Hat sponsorship.
Using git to build sources from, while a change, doesn't significantly
increase the number of packages that need building. The actual package
building - compilation - stage can take days on even the fastest
hardware. Yes, the build infrastructure is different, and yes there is
a learning curve involved, but I have found that the mechanics of
building the source is not really that different from doing it with
source RPMs. Instead of 'wget src.rpm; rpmbuild --rebuild src.rpm' you
do a 'git clone $rpm-package; git checkout $tag; get_sources.sh;
rpmbuild -ba $tree' for a full manual build; I've now done this a few
times, and it's not really difficult, just a few more keys to press.
What can't now be used is the %{BUILDTIME} embedded in the source RPM
that can give you clues as to build order; a git commit of a thousand
packages can be atomic and all at the same time.
The use of systemd has nothing at all to do with the build difficulty;
it's just another package for that purpose; likewise, the new release
numbering has nothing to do with build and QA difficulty.
...
It would appear that the package build was completed on the 4th of
May, why didn't we get a CR repo dump this time around so that CentOS
users wouldn't have to wait another month before getting critical
updates?
CentOS users who can't wait for CentOS to release 'critical' updates
really should reconsider using something else; that might be RHEL, that
might be something completely different. This is part of the calculated
risk of using CentOS, and this hasn't changed since 2.1. That's not
going to change, nor can it thanks to all the reasons Johnny mentioned.
Building a full distribution from sources can be a hard problem.
As far as the first build iteration completion date is concerned, that
should be considered a rough draft build; if the QA process finds binary
incompatibility (library linkage versions for the most part) then
several if not all packages need rebuilding as part of the QA stage. Do
you REALLY want to use first-draft stage 1 packages in production? You
can look in the %{BUILDTIME} query tag for build order; use the
following command to get the order:
rpm -qa --queryformat "%{BUILDTIME} %{NAME} %{EPOCH} %{VERSION}
%{RELEASE}\n" | sort
Or you can go through the released packages on centos.org and look at
the build dates to see how many packages were built pretty late; for
instance, bpftool-4.18.0-193.el8.x86_64.rpm apparently wasn't built in
the released version until 2020-05-29. I'm reasonably sure the first
pass at this was built probably a month earlier based on the dates of
other packages, but something was probably found in QA that required a
rebuild, or the rebuild depended on something else that was late to build.
AND since this rebuilt package HAS TO KEEP THE SAME
Name/Epoch/Version/Release (NEVR) tuple to be RHEL-compatible, the first
N=bpftool V=4.18.0 R= 193.el8 could not be released; who knows, there
may have been a dozen of the same NVR (bpftool's %{EPOCH} is (none) and
so I don't count it)... If the first N=bpftool V=4.18.0 R= 193.el8
were to be released, then how, within the RPM update decision mechanism
that only uses the EVR to update, is dnf/yum/rpm going to know the
version built on 2020-05-29 is updating the one built on say
2020-04-26? No, ${BUILDTIME} is NOT used for update decisions, sorry,
and bumping %{EPOCH} is the nuclear sledgehammer of RPM versioning and
thus is strongly discouraged. For complete compatibility you want every
package to have the same NEVR in CentOS as in RHEL except where
CentOS-specific changes had to be made (branding, mostly).
And then there's modularity in CentOS 8, which means packages might have
to build against a whole 'nother set of packages (I'm thinking
specifically of the three different PostgreSQL versions that are
modularized, or the mariadb versus MySQL modules with their libraries,
and so on) that does indeed dramatically increase the number of package
builds that not only need building but then need QA testing. Or do you
want to run untested packages in production to get the packages sooner?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 6/24/20 12:27 PM, Lamar Owen wrote:
... You can look in the %{BUILDTIME} query tag for build order; use
the following command to get the order:
rpm -qa --queryformat "%{BUILDTIME} %{NAME} %{EPOCH} %{VERSION}
%{RELEASE}\n" | sort
So, replying to my own post here, as build order is only part of the
story. Determining the contents of what was in the actual BUILDROOT at
%{BUILDTIME} can be right difficult, since the BUILDROOT is not
guaranteed to have every package that has a prior %{BUILDTIME} in it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
Am 24.06.20 um 18:37 schrieb Lamar Owen:
On 6/24/20 12:27 PM, Lamar Owen wrote:
... You can look in the %{BUILDTIME} query tag for build order; use
the following command to get the order:
rpm -qa --queryformat "%{BUILDTIME} %{NAME} %{EPOCH} %{VERSION}
%{RELEASE}\n" | sort
So, replying to my own post here, as build order is only part of the
story. Determining the contents of what was in the actual BUILDROOT at
%{BUILDTIME} can be right difficult, since the BUILDROOT is not
guaranteed to have every package that has a prior %{BUILDTIME} in it.
Additionally; I think the "build loop 0" is build on Fedora and loop 1
on the output of loop 0 and so on ... which makes things more difficult.
--
Leon
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
Am 22.06.20 um 03:02 schrieb Valeri Galtsev: > This should hopefully explain that PHP version 5.6, even patched by doing its best RedHat still may have undiscovered and not fixed bugs with security implications. One can argue, the probability of that is low. But there is no way to prove that there are none, the same as one can not prove an opposite. AFAIK, RH proactively do eval and fuzzing on software packages and is an active reporter of security vulnerabilities to upstream projects. But what I wanted to say; with Appstreams in EL8 the life cycle changes drastically. AFAIK, everything outside of BaseOS repo does not have the 10 years support. PHP 73 support ends Nov 2021 in EL8 but its supported by the PHP.NET until 6 Dec 2021. Albeit not a big difference but shows the changed game rules. -- Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
