devel May 2019

devel@lists.centos.org

34 participants
21 discussions

CentOS 8 Artwork needed
by Rich Bowen 31 Jan '20

31 Jan '20

To all the artists and designers here, we need your help. With RHEL 8 beta released, we need to start producing artwork for CentOS 8. It's time for the CentOS Artwork SIG, and anyone else that's interested in contributing to this effort, to start working on everything that will be needed for the new release. What we know we need is anaconda artwork, and new desktop backgrounds to replace the current '7' themed stuff. As we dig, we may find more things that need to be updated to the new 8 theme. Additionally, we will need to update some of the assets listed here: https://wiki.centos.org/ArtWork/Identity ... and produce new assets for 8 to be listed here: https://wiki.centos.org/ArtWork/Brand/Logo And, finally, we need someone to step up to lead this effort. While we don't yet know for certain when RHEL 8 will officially release, it's safe to assume that it's soon, and we need your help. -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

10 30

Using mirrorlist in centos-release-* packages
by Anssi Johansson 12 Sep '19

12 Sep '19

Hi, as mentioned in https://lists.centos.org/pipermail/centos-devel/2018-September/016949.html mirrorlist.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 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!

1 2

[ceph] Bringing Ceph to the Netherlands!
by Rain Leander 31 May '19

31 May '19

Come find out why leading enterprises are adopting Ceph, why Ceph is the lowest cost per gig storage solution, and how easy it is to deploy your own Ceph cluster! Event Description CFP is open until June 3rd. Please submit your presentation here. <https://zfrmz.com/E3ouYm0NiPF1b3NLBjJk> A full-day event dedicated to sharing Ceph’s transformative power and fostering the vibrant Ceph community, Ceph Day Netherlands is hosted by Utrecht Media Plaza, the Ceph community, and our friends. The expert Ceph team, Ceph’s customers and partners, and the Ceph community join forces to discuss things like the status of the Ceph project, recent Ceph project improvements and roadmap, and Ceph community news. The day ends with a networking reception, to foster more Ceph learning. -- K Rain Leander OpenStack Community Liaison Open Source Program Office https://www.rdoproject.org/ http://community.redhat.com

1 0

SCL packages in CentOS 7 that are expired and EOL
by Trevor Hemsley 30 May '19

30 May '19

Hi all I just had a glance at the various repos installed by centos-release-scl on CentOS 7 and a large number of the packages available in the CentOS version of this repo are both old and out of date and more importantly, EOL. They should be removed from our repos ASAP. I know we had/have a policy of cleaning these repos up at point release times but it's quite apparent that we have missed all of these for a number of point releases from 7.3 onwards. Thus I propose we make an exception for these and remove them anyway, regardless of point release time or not. A lot of them should have been gone for 3 years already. The following are all dead as per https://access.redhat.com/support/policy/updates/rhscl - some of them deader than others. devtoolset-3 - Oct 2016 devtoolset-4 - Nov 2017 devtoolset-6 - Nov 2018 git19 - Oct 2016 mariadb-5.5 - Oct 2016 maven30 - Oct 2016 mogodb24 - Oct 2016 mysql55 - Oct 2016 nginx16 - Oct 2016 nodejs010 - Oct 2016 perl516 - Oct 2016 php54 - Oct 2016 php55 - Oct 2016 postgresql92 - Oct 2016 python33 - Oct 2016 rh-git29 - Nov 2018 rh-mariadb100 - Apr 2018 rh-mongodb26 - Apr 2018 rh-mongodb30upg - Apr 2018 rh-mysql56 - Apr 2018 rh-nginx18 - Nov 2018 rh-nodejs4 - May 2018 rh-passenger40 - Apr 2018 rh-perl520 - Apr 2018 rh-postgresql94 - Apr 2018 rh-python34 - Apr 2018 rh-ror41 - Apr 2018 rh-ruby22 - Apr 2018 rh-thermostat16 - Oct 2016 rh-varnish4 - Nov 2018 ror40 - Oct 2016 ruby193 - Oct 2016 ruby200 - Oct 2016 rust-toolset-7 - ??? sclo-python34 - Apr 2018 thermostat1 - Oct 2016 v8314 - Apr 2018 The following go EOL this month: ==================== rh-mariadb101 - May 2019 rh-maven33 - May 2019 rh-mongodb32 - May 2019 rh-nodejs6 - May 2019 rh-postgresql95 - May 2019 rh-python35 - May 2019 rh-ror42 - May 2019 rh-ruby23 - May 2019 sclo-python35 - May 2019 sclo-ror42 - May 2019 These are not mentioned on the above page but could be part of other SCLs that are still current (maybe!) rh-eclipse46* sclo-cassandra3 - ???? sclo-git212 - ??? sclo-git25 - ??? go-toolset - no expiration date given libasan[2,3,4,5] libcilkrts, liblsan, libmpx, libtsan, libubsab[1] - ???? llvm-toolset-7 - part of devtoolset-7? sclo-subversion19 - ??? sclo-vagrant1 - ??? Trevor

10 19

Ceph Day Netherlands: CFP closes June 3rd
by Rich Bowen 28 May '19

28 May '19

Hi, folks, Sorry for the late notice, but you still have a few days. Ceph will be holding Ceph Days Netherlands on July 2nd, and the CFP closes on June 3rd, which is Monday. If you are interested in presenting, please submit your proposals *now*, at https://ceph.com/cephdays/holland-2019/ Thanks! -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

CRI-O rpm not published to public repo hence not signed
by Daniel Comnea 28 May '19

28 May '19

Hi Lokesh, If i'm not mistaken i guess you are still building/ maintaining the CRI-O rpms ? If so could you please let me know where is the CI job which builds the rpms [1] which are tagged into [2] ? The reason i'm bringing this up is because folks in K8s community are using the cri-o rpms published to [3] and that should have never happened. Now with Fabian (@arrfab) help we manage to track down that there was no request being made by you(or the SIG chair under which the cri-o falls into) to sign and publish the rpm to mirror.centos.org and that backs the issue folks raised [3]. As a solution, i can suggest one (if you are willing to accept it): 1. you follow the process and 1. tag and promote the rpms from -candidate to -testing and then to paas7-crio-114-release 2. create a ticket on bugs.c.o so our Infra folks can sign and publish the rpm which i guess will end up in [4] 2. or we can try to get it under PaaS SIG and then publish it under [5] Once all that is done then i'm happy to even announce on K8s/ CRI mailer as projects like kubespray are using it/ consuming the rpm. Cheers, Dani [1] https://cbs.centos.org/koji/buildinfo?buildID=25889 [2] https://cbs.centos.org/koji/taginfo?tagID=1704 [3] https://github.com/kubernetes-sigs/kubespray/pull/4781#issuecomment-4938274… [4] http://mirror.centos.org/centos/7/os/x86_64/Packages/ [5] http://mirror.centos.org/centos/7/paas/x86_64/

1 1

snmp walk not working in FIPS compliant algorithms
by Maheshwari, Shagun 24 May '19

24 May '19

Hi, When we attempt to do SNMP walk v3 in CentOS7 when its FIPS enabled, we get the below error: aes_misc.c(74): OpenSSL internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode! FIPS support SHA and AES. This error is coming internally and it needs changes from rpm level. When we try the same scenario in RHEL 6 servers, we don't get this error and we get output successfully. The SNMP rpm we use is net-snmp-5.7.2-28.el7.x86_64 Please let us know how we can resolve this error? Any patch is available for this or not. Regards, Shagun

2 1

libXvMC-devel EL8
by Leon Fauster 22 May '19

22 May '19

I can't find libXvMC-devel for EL8 - any ideas? -- Thanks LF

2 2

Drafting the June newsletter, contributors welcome
by Rich Bowen 21 May '19

21 May '19

I'm in the process of drafting the June newsletter, which I hope to post on Tuesday, June 4th. If you would like to contribute to it in any way, please let me know. In response to last month's newsletter, I received the following comment: "Newsletter is great if medium to expert but it’s all Greek to newbie. How about a newbie articles?" To that end, if any of you would like to contribute articles, either to the newsletter, or to the blog in general, on any topic of interest to people of any skill level, please do let me know. It's also worth noting that if you have a CentOS developer account, you can post drafts to the blog - instructions are here: https://wiki.centos.org/SpecialInterestGroup/Promo/Blog -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

[URGENT] CBS builds for ppc64le and aarch64 not landing on mirrors
by Sandro Bonazzola 16 May '19

16 May '19

Hi, yesterday I built adn released qemu-kvm-ev with fixes for Microarchitectural Store Buffer Data CVE. The build landed correctly on x86_64 at http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/?C=M;O=D but it's still missing on ppc64le at http://mirror.centos.org/altarch/7/virt/ppc64le/kvm-common/?C=M;O=D and on aarch64 at http://mirror.centos.org/altarch/7/virt/aarch64/kvm-common/?C=M;O=D the build is https://cbs.centos.org/koji/buildinfo?buildID=26025 and the mappings looks correct: https://git.centos.org/centos/cbs-content-control/blob/master/f/sign_list.p… https://git.centos.org/centos/cbs-content-control/blob/master/f/sign_list.a… Since this is an important CVE fix, can you please prioritize work on this issue? Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2019