We are pleased to announce that we'll be holding a CentOS Dojo at Oak
Ridge National Laboratories, in Oak Ridge, Tennessee, on April 16th, 2019.
ORNL is home to the fastest supercomputer in the world. It's also home
to a huge quantity of CentOS, OpenStack, Ceph, Gluster, and many other
open source projects that we love.
We are accepting talk submissions now:
https://goo.gl/forms/UBjcVbaqhwSg69Qj1
Please have a look at the schedule from our most recent Dojos -
https://wiki.centos.org/Events/Dojo/CERN2018 ,
https://wiki.centos.org/Events/Dojo/DevConfUS2018 - for some idea of
what kinds of talks are typically popular with our audiences.
We are also looking for help connecting with area businesses, both to
encourage them to attend, and also to submit their interesting use cases
as presentations.
If you'd like to help with the event in any way, please let me know, or
come discuss it on the CentOS-Promo mailing list.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166
If you want something in the December newsletter, please get it to me by
Monday. Thanks.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166
So here we go again. As one of the virtues of a programmer is laziness,
I'll just cut&paste the previous email with some modifications. You know
the drill.
RHEL 7.6 was released a few days ago and building CentOS 7.6.1810 has
just started. This would be an excellent time to remove any EOL software
you may have floating around on mirror.centos.org. mirror.centos.org
should have only supported packages available.
SIGs should explicitly state which content they want copied over from
7.5.1804 to 7.6.1810.
I'd imagine that for example ceph-jewel could be dropped because it went
EOL in July 2018. Is there some other content that could be dropped? If
you are planning to keep content available that has gone EOL upstream,
you must commit to backport any required security fixes to it.
If SIGs want to transfer some of their packages from 7.5.18004 to
7.6.1810, please let hughesjr know. You can probably simply reply to
this message to let people know of your decision. It is possible that
some other SIG depends on your packages that are going to be removed. In
that case the other SIG should probably update their packages to depend
on supported versions.
Content to be transferred over to 7.6.1810 can be specified either by
directory name, or by individual package names.
There are also various centos-release-* packages in extras,
http://mirror.centos.org/centos/7.5.1804/extras/x86_64/Packages/ ,
perhaps some of those could be trimmed as well.
You should also communicate to your users in advance that the EOL
packages will disappear, and if necessary, instruct them to migrate to a
newer supported version. Having instructions for that procedure
published somewhere would be nice.
The old content under 7.5.1804, including any EOL content, will be
archived to vault.centos.org, and that content will be available in the
vault indefinitely. The 7.5.1804 directory on mirror.centos.org will be
emptied some time after 7.6.1810 is released.
For reference and inspiration, here are some directories from
mirror.centos.org, including both up-to-date content and potentially EOL
content. SIGs should review the list to make sure these directories can
be copied over to 7.6.1810 when that time comes. Making the decisions
now would save a bit of time at 7.6.1810 release time.
cloud/x86_64/openstack-ocata
cloud/x86_64/openstack-pike
cloud/x86_64/openstack-queens
cloud/x86_64/openstack-rocky
configmanagement/x86_64/ansible26
configmanagement/x86_64/yum4
dotnet
nfv/x86_64/fdio/vpp/vpp-1710
nfv/x86_64/fdio/vpp/vpp-1801
nfv/x86_64/fdio/vpp/vpp-1804
nfv/x86_64/fdio/vpp/vpp-1807
opstools/x86_64/common
opstools/x86_64/fluentd
opstools/x86_64/logging
opstools/x86_64/perfmon
opstools/x86_64/sensu
paas/x86_64/openshift-origin
paas/x86_64/openshift-origin13
paas/x86_64/openshift-origin14
paas/x86_64/openshift-origin15
paas/x86_64/openshift-origin36
paas/x86_64/openshift-origin37
paas/x86_64/openshift-origin38
paas/x86_64/openshift-origin39
paas/x86_64/openshift-origin310
sclo/x86_64/rh/devassist09
sclo/x86_64/rh/devtoolset-3
sclo/x86_64/rh/devtoolset-4
sclo/x86_64/rh/devtoolset-6
sclo/x86_64/rh/devtoolset-7
sclo/x86_64/rh/git19
sclo/x86_64/rh/go-toolset-7
sclo/x86_64/rh/httpd24
sclo/x86_64/rh/llvm-toolset-7
sclo/x86_64/rh/mariadb55
sclo/x86_64/rh/maven30
sclo/x86_64/rh/mongodb24
sclo/x86_64/rh/mysql55
sclo/x86_64/rh/nginx16
sclo/x86_64/rh/nodejs010
sclo/x86_64/rh/passenger40
sclo/x86_64/rh/perl516
sclo/x86_64/rh/php54
sclo/x86_64/rh/php55
sclo/x86_64/rh/postgresql92
sclo/x86_64/rh/python27
sclo/x86_64/rh/python33
sclo/x86_64/rh/python34
sclo/x86_64/rh/rh-eclipse46
sclo/x86_64/rh/rh-git29
sclo/x86_64/rh/rh-haproxy18
sclo/x86_64/rh/rh-java-common
sclo/x86_64/rh/rh-mariadb100
sclo/x86_64/rh/rh-mariadb101
sclo/x86_64/rh/rh-mariadb102
sclo/x86_64/rh/rh-maven33
sclo/x86_64/rh/rh-maven35
sclo/x86_64/rh/rh-mongodb26
sclo/x86_64/rh/rh-mongodb30upg
sclo/x86_64/rh/rh-mongodb32
sclo/x86_64/rh/rh-mongodb34
sclo/x86_64/rh/rh-mongodb36
sclo/x86_64/rh/rh-mysql56
sclo/x86_64/rh/rh-mysql57
sclo/x86_64/rh/rh-nginx18
sclo/x86_64/rh/rh-nginx110
sclo/x86_64/rh/rh-nginx112
sclo/x86_64/rh/rh-nodejs4
sclo/x86_64/rh/rh-nodejs6
sclo/x86_64/rh/rh-nodejs8
sclo/x86_64/rh/rh-perl520
sclo/x86_64/rh/rh-perl524
sclo/x86_64/rh/rh-perl526
sclo/x86_64/rh/rh-php56
sclo/x86_64/rh/rh-php70
sclo/x86_64/rh/rh-php71
sclo/x86_64/rh/rh-postgresql10
sclo/x86_64/rh/rh-postgresql94
sclo/x86_64/rh/rh-postgresql95
sclo/x86_64/rh/rh-postgresql96
sclo/x86_64/rh/rh-python35
sclo/x86_64/rh/rh-python36
sclo/x86_64/rh/rh-redis32
sclo/x86_64/rh/rh-ror42
sclo/x86_64/rh/rh-ror50
sclo/x86_64/rh/rh-ruby23
sclo/x86_64/rh/rh-ruby24
sclo/x86_64/rh/rh-ruby25
sclo/x86_64/rh/rh-scala210
sclo/x86_64/rh/rh-thermostat16
sclo/x86_64/rh/rh-varnish4
sclo/x86_64/rh/rh-varnish5
sclo/x86_64/rh/ror40
sclo/x86_64/rh/ror41
sclo/x86_64/rh/ruby193
sclo/x86_64/rh/ruby200
sclo/x86_64/rh/ruby22
sclo/x86_64/rh/rust-toolset-7
sclo/x86_64/rh/thermostat1
sclo/x86_64/rh/v8314
sclo/x86_64/sclo/sclo-cassandra3
sclo/x86_64/sclo/sclo-git25
sclo/x86_64/sclo/sclo-git212
sclo/x86_64/sclo/sclo-httpd24more
sclo/x86_64/sclo/sclo-php54
sclo/x86_64/sclo/sclo-php55
sclo/x86_64/sclo/sclo-php56
sclo/x86_64/sclo/sclo-php70
sclo/x86_64/sclo/sclo-php71
sclo/x86_64/sclo/sclo-python27
sclo/x86_64/sclo/sclo-python34
sclo/x86_64/sclo/sclo-python35
sclo/x86_64/sclo/sclo-ror42
sclo/x86_64/sclo/sclo-subversion19
sclo/x86_64/sclo/vagrant1
storage/x86_64/ceph-jewel
storage/x86_64/ceph-luminous
storage/x86_64/gluster-3.10
storage/x86_64/gluster-3.12
storage/x86_64/gluster-4.0
storage/x86_64/gluster-4.1
storage/x86_64/gluster-5
virt/x86_64/azure
virt/x86_64/kubernetes19
virt/x86_64/kubernetes110
virt/x86_64/kvm-common
virt/x86_64/libvirt-latest
virt/x86_64/ovirt-4.2
virt/x86_64/xen-46
virt/x86_64/xen-48
virt/x86_64/xen-410
In addition to those, ovirt-4.1 should have already been removed, but it
is still available in the altarch branch for aarch64 and ppc64le. This
is an error, which will hopefully get fixed this round.
Hi Folks,
I have a couple of problems and proposals that I'd like to discuss for
bugs.centos.org:
PROBLEM 1:
Currently when a user reports an issue it's very difficult for them to
know where to route things properly. The confusion seems to be between
projects and categories. For example, Ci.centos.org Ecosystem Testing is
the category under the Buildsys project that's supposed to be used for
both infrastructure issues and new account requests. It's not
immediately obvious that the user needs to select the Buildsys project
to get there though. If they do make it that far, but forget to choose
the Ci.centos.org ecosystem testing category , it may get assigned by
default to someone who are active in CentOS but outside of maintaining
the CICO infra (sorry alphacc and range!).
PROPOSAL: Move CentOS CI to it's own "Project" so that it shows up in
the dropdown list, and allow us to segment CI requests from SIG requests.
PROBLEM 2:
In the Buildsys project, once someone reports and issue, they can no
longer update it (ex: if they chose the wrong category, or no longer
have the issue and would like to close it). In a few projects like
Buildsys (and CICO) it makes sense to allow these folks a little freedom
in modifying some of the bug fields.
PROPOSAL: For the Buildsys and CICO projects -only- allow Reporters to
Close, Reopen, and Update their own issues. This would leave the Distro
and SIG projects unaffected.
I can make these changes if we're all happy. Are there any objections?
--
Brian Stinson
CentOS Infrastructure Team
If you would like to have anything in the December newsletter, please
get me something by Monday. The newsletter will go out on Tuesday,
December 4th.
Thanks.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166
Hello all,
I've released livecd-tools v26.0 and it is making its way to Fedora
and Mageia now.
It is currently available in Rawhide, and will be in updates-testing
for Fedora 28 and 29 soon.
For Mageia, I've pushed it into Cauldron. It will be part of the
upcoming Mageia 7.
## What's new
This update adds some small changes to re-introduce compatibility with
EL7 distributions, such as Red Hat Enterprise Linux 7, CentOS 7, and
so on. This was made possible by the inclusion of DNF into Red Hat
Enterprise Linux 7.6. The changes were contributed by Pablo Greco from
the CentOS Project. Builds of livecd-tools and appliance-tools will be
provided in CentOS Extras at some point in the near future by Pablo.
ISO creation is now done using GNU Xorriso rather than cdrkit. This
was done because Xorriso is actively developed and receiving new
features. Also now, if the target distribution supports it, ISOs can
be created with ia32 and x64 UEFI support.
In addition, appliance-tools is now Python 3 compatible. The
ec2-converter tool is deprecated and slated for removal in the next
release, due to lack of maintenance and being utterly broken. If there
are any users of this tool, patches and pull requests welcome on
pagure.io: https://pagure.io/appliance-tools
RISC-V is now experimentally supported, thanks to David Abdurachmanov
of the Fedora RISC-V group.
Python 2 packaging of the imgcreate module has been dropped in Fedora
30+ and Mageia 7. It is still supported for CentOS 7.
## Now what?
Please check out the new release!
If you have any issues with livecd-tools or appliance-tools, please
file them either in Fedora or Mageia bug trackers, or preferably at
the appropriate project issue trackers:
* livecd-tools: https://github.com/livecd-tools/livecd-tools/issues
* appliance-tools: https://pagure.io/appliance-tools/issues
Have fun making live Linux systems!
Best regards,
Neal
--
真実はいつも一つ!/ Always, there's only one truth!
I am hitting infra issues with OpenShift running on CentOS CI.
Is it the right group to address those kind of issue? or maybe you can
refer me to an appropriate ML.
Thanks in advance,
Liora
--
*Liora Milbaum*
Senior Principal Software Engineer
RHV/CNV DevOps
EMEA VIRTUALIZATION R&D
T: +972-54-6560051
<https://red.ht/sig>
Hi folks,
I wanted to revisit the idea of having a dedicated "ceph" system
account for CBS.
I'm pitching using CBS to other members of my team next week so we can
use a central build system in lieu of building our own solution. They
are going to be turned off by the idea that any automatic interactions
with CBS (eg with Jenkins) will have to use my "ktdreyer" account
credentials.
Could I please have a "ceph-jenkins" system account with longer-lived
credentials?
- Ken
hi gents
would anybody know why tpm_rng is gone from 3.10.0-957.el7.x86_64 ?
I need it on my oldish heavy boxes, so do lots of others I would imagine.
many thanks, L.