Hi,
There have been few unexpected failure emails today from centos
community container pipeline, due to pods failing to run the builds in
the cluster.
Please ignore today's failure emails we are working to get things
sorted.
We would also need to update the nodes, so will take some
maintenance window this week (we will keep a separate thread posting for
that).
We are sorry for the inconvenience caused.
Note: There is no affect on the availability of registry.centos.org
(…
[View More]build logs will not be available for sometime).
Thanks and Regards
Bama Charan Kundu
[View Less]
I've started testing with the "cr" repositorory enabled, and we are
going to have a *lot* of problems building EPEL packages unless we get
well ahead of the game.
RHEl has elected to publish their python3 modules as "python3-module",
and to obsolete "python36-module" names. All well and good, this will
help provide upgrade paths from EPEL. The problem is that they've also
updated "pythone_pkgversion" to be "3", instead of "36". And every
package that uses "python%{python3_pkgversion} is going …
[View More]to break if
the package is published as an EPEL package, such asl
"python36-pylint", and is not available as a "python3-pylint" package.
It's potentially soluble by every single EPEL package being updated to
"Provide:" python3-module, as well as python36-module. But then that
gets into the "we never, never, never overlap with RHEL published
packages". So the technological fix that allows Red Hat to Obsolete:
the EPEL versions, as they just did with "python3" obsoleting ade past
and over packages as they just die, with "python3-devel" and
"python3-devel", is going to have to be done with almost every python
EPEL package and those packages ingested into the RHEL upstream
repository.
I'm not sure where to best resolve this. I ran into it while trying to
update a "mock" SRPM with the "cr" repository enabled, and savagery
ensued with dependencies on "python3-pylint", for which there is not
EPEL or CentOS package.
[View Less]
Hi, as mentioned in
https://lists.centos.org/pipermail/centos-devel/2018-September/016949.htmlmirrorlist.centos.org has been updated to produce mirror lists for SIG
content as well. Some centos-release-* packages have already been
modified to use mirrorlist.centos.org instead of mirror.centos.org, but
many still point to mirror.centos.org.
Most of mirror.centos.org hosts are also used for seeding the 600+
external mirrors we have. By directing some of their download traffic to
external …
[View More]mirrors we can offer faster sync speeds for those external
mirrors, and for people downloading individual rpms from
mirror.centos.org. Second, most of those external mirrors offer faster
download speeds to end users than what could be achieved by downloading
from mirror.centos.org, so the users will benefit from this change as
well. The better geographical coverage does not hurt either.
mirror.centos.org nodes are donated servers, and it would be kind to the
sponsors to use their bandwidth sparingly.
The .repo files should be modified so that the current baseurl line gets
commented out and a mirrorlist entry gets added, like this:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch…
#baseurl=http://mirror.centos.org/$contentdir/$releasever/storage/$basearch/gluster-4.1/
Note that mirrorlist.c.o can automatically choose between main and
altarch content based on the arch parameter. The repo names are
constructed from the repository path by stripping away the architecture
and changing any slashes to dashes: sclo/x86_64/rh -> sclo-rh,
sclo/x86_64/sclo -> sclo-sclo, paas/x86_64/openshift-origin311 ->
paas-openshift-origin311, storage/x86_64/gluster-5 -> storage-gluster-5
etc. You can use 'curl' to check what mirrorlist outputs for your
repository.
New repos are added to mirrorlist.centos.org automatically once the
repository hits mirror.centos.org. That script is currently run every
three hours. I guess it could be run more frequently (it's fairly
lightweight), but you should give the external mirrors a few hours to
sync before announcing your release anyway.
You can either submit an update to your current centos-release-* file
now, or wait until you need to create a new centos-release-* package for
other reasons such as releasing softwarepackage-(version+1) which uses
different paths. My recommendation would be to submit an update to your
current centos-release-* package, so that you would not need to worry
about this when you eventually need to publish a new one for other
reasons. We released an updated centos-release package for CentOS
AltArch before 7.6.1810 was released for this exact reason, ie. we
didn't need to worry about this change at 7.6.1810 release time.
Other people (such as bstinson, arrfab and hughesjr) can probably help
with creating and publishing an updated centos-release-* package, but
the usual tagging procedure to extras will apply. The SIG Guide
https://wiki.centos.org/SIGGuide should have all the needed details for
this (if not, complain to bstinson). It is highly recommended to
actually test your new centos-release-* package from buildlogs before
you ask that package to be signed and pushed to extras.
The holiday season is fast approaching so (I) don't expect much activity
regarding these changes in the following days. I'm hoping that the SIGs
would take a look at this in early 2019, though. Thanks to those SIGs
who have already made these changes to their centos-release-* packages!
If you have questions, feel free to ask either here or on #centos-devel.
Thanks for your time!
[View Less]
For all the c7 SIGs, if you have content that you want removed (to make
inactive) when we create the new 7.7.1908 tree, please let me know here
what needs to be removed.
If all files in a specific directory can be removed, you can just list
the directory.
You will also obviously need to make any changes to your
centos-release-* files to remove those file locations from your repos.
After we release 7.7.1908 .. we will copy over the SIG directories prune
the SIG content. The http://…
[View More]mirror.centos.org/centos/7/<repo>/ paths
will then be shifted to the new 7.7.1908 tree.
I expect that some time early next week we will release the CR content
.. with the full release coming 7 to 14 days after that .. so full
release likely some time between 29 August to 6 September 2019.
If you don't tell us to remove content, we will move everything over as is.
Thanks,
Johnny Hughes
[View Less]
So, updated to CR yesterday evening, and for the most part things are
ok. However:
[lowen@dhcp-pool101 ~]$ sudo yum --enablerepo=cr update
.....
Resolving Dependencies
--> Running transaction check
---> Package python-urllib3.noarch 0:1.10.2-5.el7 will be updated
---> Package python-urllib3.noarch 0:1.10.2-7.el7 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
…
[View More]Package Arch Version Repository Size
================================================================================
Updating:
python-urllib3 noarch 1.10.2-7.el7 cr 103 k
Transaction Summary
================================================================================
Upgrade 1 Package
Total download size: 103 k
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for cr
python-urllib3-1.10.2-7.el7.noarch.rpm | 103 kB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating :
python-urllib3-1.10.2-7.el7.noarch 1/2
Error unpacking rpm package python-urllib3-1.10.2-7.el7.noarch
error: unpacking of archive failed on file
/usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname:
cpio: rename
Verifying :
python-urllib3-1.10.2-7.el7.noarch 1/2
python-urllib3-1.10.2-5.el7.noarch was supposed to be removed but is not!
Verifying :
python-urllib3-1.10.2-5.el7.noarch 2/2
Failed:
python-urllib3.noarch 0:1.10.2-5.el7 python-urllib3.noarch
0:1.10.2-7.el7
Complete!
[lowen@dhcp-pool101 ~]$
[View Less]
Hi Folks,
The CR (https://wiki.centos.org/AdditionalResources/Repositories/CR)
repository was released last week. We have regenerated all the
CentOS 7 buildroots in CBS so you can build against the content that
will make it into the next point-release of CentOS Linux.
Machines in ci.centos.org are available with CR as well so you may
continue your testing.
We are currently in Point-release Freeze which means anything tagged for
release will *NOT* get pushed out to mirror.centos.org and we …
[View More]will be
holding new push requests until we have a GA point-release.
If there are any questions please find us here or in #centos-devel on
Freenode.
Happy building and testing !
--
Thomas 'alphacc' Oulevey and the CBS team.
[View Less]