devel

devel@lists.centos.org

3 participants
4654 discussions

building nfs-ganesha for ceph
by Ken Dreyer 05 Dec '18

05 Dec '18

Hi Niels and Kaleb, I'm wondering how we could best build nfs-ganesha's ceph FSALs in CBS. Right now, since we'll likely support multiple versions of nfs-ganesha simultaneously for different versions of Ceph, I'm leaning towards using a custom "dist tag" like thing in the Release field so we don't collide with what Kaleb's doing at http://cbs.centos.org/koji/packageinfo?packageID=98 Eventually it would be nice to have a unified nfs-ganesha build shared between Ceph and Gluster. If we built it in storage7-common-candidate, we would have to tag gluster and ceph into that, which sounds kinda messy, because you only get to choose one version of each. It'd be more manageable to have a separate set of tags and targets just for nfs-ganesha versions. Like: storage7-nfs-ganesha-26-el7 storage7-nfs-ganesha-27-el7 ... etc But that still leaves the problem of shipping a nfs-ganesha-gluster sub-package that will not have its runtime deps fulfilled in http://mirror.centos.org/centos/7/storage/x86_64/ceph-nautilus/ . Vice versa, we'd have a nfs-ganesha-ceph sub-package that lacks runtime deps in http://mirror.centos.org/centos/7/storage/x86_64/gluster-5/ What do you think? Just have separate nfs-ganesha builds for now? - Ken

3 5

building nfs-ganesha against older Ceph versions
by Ken Dreyer 05 Dec '18

05 Dec '18

Hi Matt, We're discussing building + distributing nfs-ganesha in centos-devel, https://lists.centos.org/pipermail/centos-devel/2018-December/017121.html Does it make sense to build nfs-ganesha V2.7 against Luminous's librgw and libcephfs, and then also allow users to install that build along with Nautilus' newer librgw and libcephfs? It sounds like this is what Gluster's doing with their ABI guarantees for libgfapi.so. The idea is that we'd always build against the "oldest supported" version of Ceph, but distribute it so that Luminous and Nautilus users would install the same libfsalrgw.so and libfsalceph.so binaries. - Ken

1 0

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

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