devel

devel@lists.centos.org

2 participants
4652 discussions

Pushing oVirt 4.3 packages to buildologs
by Sandro Bonazzola 05 Dec '18

05 Dec '18

Hi, now that 7.6 is out, can you please have a look at https://bugs.centos.org/view.php?id=15480 ? It will help getting ready for oVirt 4.3. 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>

1 0

CentOS 7.6.1810 release available for builds in CBS/Koji
by Fabian Arrotin 05 Dec '18

05 Dec '18

Hi, As announced (https://lists.centos.org/pipermail/centos-announce/2018-December/023082.html) , CentOS 7.6.1810 is now available and realeased for the following arches : x86_64, aarch64, ppc64le, armhfp So that release is now the default one for the CBS/koji build tasks (and all koji regen-repos tasks are currently running) That means that for your next builds, you'll be building against 7.6.1810 (even if technically that was already the case with the 7.5.1804+updates+CR repositories) That should also mean the end of the "freeze" wrt pushing tagged pkgs for release to mirror.centos.org -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

3 5

[URGENT] qemu-kvm-ev packages for CentOS 7.6
by Sandro Bonazzola 05 Dec '18

05 Dec '18

Hi, just got following report and indeed the new qemu-kvm-ev-2.12 is not in CentOS 7.6 repo despite it's tagged for release: http://cbs.centos.org/koji/buildinfo?buildID=24629 qemu-kvm-ev needs to be aligned with kernel / libvirt and other deps to properly work so we need the build to be added to the 7.6 repos as soon as possible. Can you please check where it did got stuck and let it in? Thanks, Il giorno mar 4 dic 2018 alle ore 16:03 Morten Stevens < mstevens(a)imt-systems.com> ha scritto: > Hi Sandro, > > Just a small question: Is it possible to update the qemu-kvm-ev packages > for CentOS 7.6 to qemu-kvm-ev-2.12.0-18.el7_6.1.1? > http://mirror.centos.org/centos-7/7.6.1810/virt/x86_64/kvm-common/ > > Actually, there is only the latest release for CentOS 7.5 > (qemu-kvm-ev-2.10.0-21.el7_5.7.1) available. > > Thank you very much. > > Best regards, > > Morten > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 2

Volunteer needed: Track chair at FOSDEM Dojo
by Rich Bowen 04 Dec '18

04 Dec '18

I have a volunteer to be track chair for half the day at the FOSDEM Dojo, and I'm looking for one or more people to take another half day. A track chair is responsible for: * Speaker intro * Telling the speaker when they have 10, 5, 0 minutes left, and dragging them off stage when they go over * Telling the audience to turn off their beeping devices, and to use the mic when they ask questions * Announcing what's next in the other room, so that people can switch if they desire * Ensuring that people in the room behave in a way that is compatible with our community ethos --Rich -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

new repo for "centos-release-ceph-nautilus"
by Ken Dreyer 04 Dec '18

04 Dec '18

Hi Niels, I'm looking to create a new "centos-release-ceph-nautilus" package, like the "luminous" one we have today at https://github.com/CentOS-Storage-SIG/centos-release-ceph-luminous I'm wondering if it would be easier to keep all of these in a single "centos-release-ceph" repository, with per-release branches. Would you be up for creating a https://github.com/CentOS-Storage-SIG/centos-release-ceph repo? - Ken

6 13

CentOS Dojo at ORNL, April 16th 2019
by Rich Bowen 04 Dec '18

04 Dec '18

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

2 2

Monday deadline to get something into the December newsletter
by Rich Bowen 30 Nov '18

30 Nov '18

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

1 0

SIGs: Possibility to drop EOL content at 7.6.1810 release time
by Anssi Johansson 28 Nov '18

28 Nov '18

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.

7 12

Some propsed changes in bugs.centos.org (permissions updates, and reorganization)
by Brian Stinson 28 Nov '18

28 Nov '18

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

3 3

SIG reports for December newsletter?
by Rich Bowen 27 Nov '18

27 Nov '18

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel