devel

devel@lists.centos.org

8 participants
4623 discussions

AltArch on buildlogs.centos.org
by Karanbir Singh 11 Jul '16

11 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Last week I finished the work to get altarch content pushed via cbs.centos.org to buildlogs as a first step towards wider release options opening up. Today the scripts are in production and I've incldued the list below to indicate content currently in that push queue. It should be publicly visible in a few minutes time. What this means is that for any tag, where the SIG has requested push - - we can now support aarch64, ppc64, ppc64le, armhfp and i386 content built, tested and delivered via the public community services ( cbs.centos.org / ci.centos.org / buildlogs.centos.org ) and then signed released via whatever delivery mechanism is already in place ( isos, disk media, cloud images, containers, livemedia, rpm repos, vagrant boxs etc ). There are still a few considerations to work through on the build side however. There is no clear path within our existing buildsystem ( koji ) to work with similar content, only different by the intendant target architecture and how the relationships work between build's and status'. Thomas, Brian and I spent an evening last week working through some of these options, and I believe Thomas is going to re-iterate the options in the coming days and we'll need to work through those and arrive at whatever makes most sense in the immediate future - and work on a bigger/better plan longer term. What I do recommend is going through the previous threads on this subject on the centos-devel list ( and there have been a few ), so as to update yourself on the concerns ( they remain largely unchanged, just a lot more thought and understanding now exists for some of them, atleast from my side ). Regards, - -------- Forwarded Message -------- Subject: AltArch Buildlogs Push Date: Mon, 11 Jul 2016 12:13:08 +0000 N: 7/cloud/x86_64/openstack-liberty/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/cloud/x86_64/openstack-kilo/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/cloud/x86_64/openstack-mitaka/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/cloud/x86_64/openstack-newton/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-api-3.7.13-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.7/ glusterfs-api-devel-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-cli-3.7.13-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.7/ glusterfs-client-xlators-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-devel-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-extra-xlators-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-fuse-3.7.13-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ glusterfs-ganesha-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-geo-replication-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-libs-3.7.13-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ glusterfs-rdma-3.7.13-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ glusterfs-resource-agents-3.7.13-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-server-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-gluster-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-mount-9P-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-nullfs-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-proxy-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-vfs-2.3.2-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-xfs-2.3.2-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ python-gluster-3.7.13-1.el7.noarch.rp m N: 7/storage/aarch64/gluster-3.7/ userspace-rcu-0.7.16-2.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.7/ userspace-rcu-devel-0.7.16-2.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.6/ glusterfs-resource-agents-3.6.9-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-api-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-api-devel-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-cli-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-client-xlators-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-coreutils-0.0.1-0.1.git259f269.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-devel-3.8.1-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.8/ glusterfs-extra-xlators-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-fuse-3.8.1-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ glusterfs-ganesha-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-geo-replication-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-libs-3.8.1-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ glusterfs-rdma-3.8.1-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ glusterfs-resource-agents-3.8.1-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-server-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ python-gluster-3.8.1-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.8/ userspace-rcu-0.7.16-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ userspace-rcu-devel-0.7.16-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ babeltrace-1.2.4-3.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-base-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-common-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-devel-compat-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ cephfs-java-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-fuse-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-libs-compat-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-mds-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-mon-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-osd-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-radosgw-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-selinux-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-test-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ fcgi-2.4.0-25.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ fcgi-devel-2.4.0-25.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ leveldb-1.12.0-5.el7.1.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ leveldb-devel-1.12.0-5.el7.1.aarch64.r pm N: 7/storage/aarch64/ceph-jewel/ libbabeltrace-1.2.4-3.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libbabeltrace-devel-1.2.4-3.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libcephfs1-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libcephfs1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libcephfs_jni1-10.2.2-0.el7.aarch64.rp m N: 7/storage/aarch64/ceph-jewel/ libcephfs_jni1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librados2-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librados2-devel-10.2.2-0.el7.aarch64.r pm N: 7/storage/aarch64/ceph-jewel/ libradosstriper1-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libradosstriper1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librbd1-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librbd1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librgw2-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librgw2-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libunwind-1.1-10.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libunwind-devel-1.1-10.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ lttng-ust-2.4.1-1.el7.1.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ lttng-ust-devel-2.4.1-1.el7.1.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-ceph-compat-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-cephfs-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-mock-1.0.1-7.1.el7.noarch.rpm N: 7/storage/aarch64/ceph-jewel/ python-rados-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-rbd-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-tox-1.4.2-8.el7.noarch.rpm N: 7/storage/aarch64/ceph-jewel/ rbd-fuse-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ rbd-mirror-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ rbd-nbd-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ userspace-rcu-0.7.16-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ userspace-rcu-devel-0.7.16-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ xmlstarlet-1.6.1-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ yasm-1.2.0-4.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ yasm-devel-1.2.0-4.el7.aarch64.rpm N: 7/paas/aarch64/openshift-future/ ansible-2.1.0.0-1.el7.noarch.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXg4/bAAoJEI3Oi2Mx7xbtCjkIANHy6FKFtWWCocNJZD1WA1Ap WJsX4Un1dvLSv/Sa/f7JXt/0bA6wnueMzY2uZZyAjxrpup4UN8sjNW0D/3QrDf9o 8o3+YQz7hp/Wy/CoYXTQSXvjR6Iflzsx9FX/CqHpqUbHB2LaHi9fKG+d2ZsOaFiS SCe809NnCxbM1RMoLMdFvsC1GO8SfZlEb3P9JMCVaPzJqj+zhkSodvHIHIvO6Z8z m7kgktznRo29FkUYHl/nnU1t4v2+xYxNhTqFTEe90jlIOordrePsdHlZzaWb/3JW kwqLnYQs1k7OphUno2lqd9lNfN0uCZ1PAKOUoQuuavGp9drfIhu44LMg/4kep90= =/QJh -----END PGP SIGNATURE-----

2 1

Feedback needed: ideas for the Vagrant images
by Laurentiu Pancescu 11 Jul '16

11 Jul '16

Hi there, I would appreciate some feedback on a few ideas for our Vagrant images. Our CentOS images for Vagrant are currently not setup according to the upstream recommendations for base boxes, and I'd like to change that. [1] Here's the list of necessary modifications: I. root password should be 'vagrant': already filed by Lalatendu Mohanty as issue #30 on GitHub [2]. I should mention that Karanbir Singh has some reservations related to security. However, the box already has passwordless sudo, and changing the root password is just a "sudo passwd" away (I tried, it warns about a bad password, but it accepts it). Although public key auth is enabled, password-based authentication isn't disabled, and sshd will happily let anyone log in to any public box as vagrant:vagrant. We should probably only allow local password logins (on the console), for both root and vagrant; not sure if the best way to enforce this is sshd_config or PAM. II. use /vagrant as the sync directory: we currently use /home/vagrant/sync, this change is already planned for the release following 1606 III. "UseDNS no" in sshd_config: this would make connections via ssh faster Additional ideas for optimization: IV. disable requiretty in /etc/sudoers: this allows users to enable the pipelining feature of the Ansible provisioner, which significantly increases its speed (it's about 2 times faster in my tests). [3] V. set GRUB_TIMEOUT to 1 or 0: this reduces or eliminates the waiting time before the default kernel is booted (the VM runs generally without a display, so it makes no sense to wait there) Best regards, Laurențiu [1] https://www.vagrantup.com/docs/boxes/base.html [2] https://github.com/CentOS/sig-cloud-instance-build/issues/30 [3] https://docs.ansible.com/ansible/intro_configuration.html#pipelining

5 7

Rebuilding RDO for ppc64le
by Xiandong Meng 11 Jul '16

11 Jul '16

In RDO Austin BOF meeting, I have proposed to rebuild RDO packages for ppc64le. And a few discussions have been carried over since then. Now with the power builders up and running on cbs (http://cbs.centos.org/koji/hosts) I'd like to write to the mailinglist for more broad discussing. The goal is to rebuild RDO packages for ppc64le in CBS. And we will start with Mitaka release as it is a recent stable release. And one of the idea was to 1. create a new tag (cloud7-openstack-mitaka-candidate-ppc64le?) 2. import all 'noarch' builds from cloud7-openstack-mitaka-* tags 3. send all required packages to the builder 4. test resulting packages for installation & function validation (via ci pipeline?) 5. import/merge all of them to propose cloud7-openstack-* tag I think we need to proceed with this work without touching x86 tags until it is ready for merge. I have experience building the packages with local mock build environment, but i may need help to initiate that build work in CBS. Any comments/suggestions are welcome. Regards, Alex Meng <mengxiandong(a)gmail.com> mengxiandong(a)gmail.com

3 2

[cockpit] Broken dependencies in CentOS Extras
by Haïkel 08 Jul '16

08 Jul '16

Hi, while running repoclosure on Cloud SIG repositories, I found out that cockpit had missing dependencies. <snip> Last metadata expiration check: 0:00:02 ago on Wed Jul 6 19:53:59 2016. package: cockpit-ostree-0.108-1.el7.centos.x86_64 from centos-extras unresolved deps: rpm-ostree-client >= 2015.11-1 /usr/libexec/rpm-ostreed package: cockpit-selinux-0.108-1.el7.centos.noarch from centos-extras unresolved deps: setroubleshoot-server >= 3.3.3 </snip> Could be fine, but it's best to check with you guys. Regards, H.

4 3

Re: [CentOS-devel] [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack
by Jim Perrin 08 Jul '16

08 Jul '16

On 07/08/2016 03:35 AM, Alan Pevec wrote: > On Fri, Jul 8, 2016 at 4:00 AM, Haïkel <hguemar(a)fedoraproject.org> wrote: >> 2016-07-07 17:41 GMT+02:00 Jim Perrin <jperrin(a)centos.org>: > ... >>> I might suggest that for now (until we get the mirror bits sorted), we >>> create a centos-release-mitaka-altarch package. This would avoid needing >>> to mess with the existing x86_64 bits. once everything is aligned, then >>> we can obsolete/provides the replacement and use the standard package >>> across all architectures. >> >> Works for me. > > I didn't understand why we need separate release -altarch package. I > understand we do need separate CBS tags but they could be still mapped > into the same per-arch locations under > http://buildlogs.centos.org/centos/7/cloud/ and > http://mirror.centos.org/centos/7/cloud/ so that current OpenStack > CloudSIG .repo [1] which uses $basearch will work. Mappings for > testing repo request (e.g. for RDO Newton [2]) would be: > The problem here is that the aarch64 builds are currently at mirror.centos.org/altarch/ not at /centos/, so either way we'll end up with split repositories for the architecture. I'm only suggesting a second package as a short term solution until we come up with a better way to manage this. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

1 0

New CentOS Atomic Host release available for download
by Jason Brooks 08 Jul '16

08 Jul '16

An updated version of CentOS Atomic Host (tree version 7.20160707) is now available for download[1], featuring updated versions of docker (1.10.3) and the atomic run tool (1.10.5). CentOS Atomic Host is a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host. [1] https://wiki.centos.org/SpecialInterestGroup/Atomic/Download CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org. CentOS Atomic Host includes these core component versions: - docker-1.10.3-44.el7.centos.x86_64 - kubernetes-1.2.0-0.12.gita4463d9.el7.x86_64 - kernel-3.10.0-327.22.2.el7.x86_64 - atomic-1.10.5-5.el7.x86_64 - flannel-0.5.3-9.el7.x86_64 - ostree-2016.5-3.atomic.el7.x86_64 - etcd-2.2.5-2.el7.0.1.x86_64 - cloud-init-0.7.5-10.el7.centos.1.x86_64 Upgrading If you're running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command: $ sudo atomic host upgrade Images Vagrant CentOS-Atomic-Host-7-Vagrant-Libvirt.box (467 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (477 MB) are Vagrant boxes for Libvirt and Virtualbox providers. The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host) For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed: $ vagrant init centos/atomic-host && vagrant up --provider virtualbox ISO The installer ISO (751 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This image allows users to control the install using kickstarts and to define custom storage, networking and user accounts. This is the recommended option for getting CentOS Atomic Host onto bare metal machines, or for generating your own image sets for custom environments. QCOW2 The CentOS-Atomic-Host-7-GenericCloud.qcow2 (1.1 GB) image is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own NoCloud iso image. Amazon Machine Images Region Image ID us-east-1 ami-956fe882 us-west-2 ami-17569677 us-west-1 ami-191e5879 eu-west-1 ami-a06601d3 eu-central-1 ami-c431dbab ap-southeast-1 ami-9638e5f5 ap-northeast-1 ami-fc867b9d ap-southeast-2 ami-6fab800c ap-northeast-2 ami-aca369c2 sa-east-1 ami-30f96d5c SHA Sums 0eb6fe98706c72635d2f156d3f9cbc4447db3234dafd792ed2b966a562695dcf CentOS-Atomic-Host-7.1606-GenericCloud.qcow2 3af5dba377f31f52817820f8b940d0490da11d74d01edd70182171f21382fc65 CentOS-Atomic-Host-7.1606-GenericCloud.qcow2.gz d28b3f21de85c6c072e277bf873d1657364f6b82f08c91b05ed001ceadb07b79 CentOS-Atomic-Host-7.1606-GenericCloud.qcow2.xz ee98acb5a50288e03dc052d4ae5cf0ccbab518f2f15f35500217c90d8088d627 CentOS-Atomic-Host-7.1606-Installer.iso 43ca397be511a32b3c750a73474039f965d6cc5c7dcfb74846e66366f5d758db CentOS-Atomic-Host-7.1606-Vagrant-Libvirt.box d458714f89b1ee3d4e4b7b097877cec9ceec5e651fec9374b4457e5a6c172f3d CentOS-Atomic-Host-7.1606-Vagrant-Virtualbox.box Release Cycle The CentOS Atomic Host image follows the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they're rebuilt and included in new images. After the images are tested by the SIG and deemed ready, we announce them. Getting Involved CentOS Atomic Host is produced by the CentOS Atomic SIG, based on upstream work from Project Atomic. If you'd like to work on testing images, help with packaging, documentation -- join us! The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you'll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel mailing list if you'd like to discuss the direction of Project Atomic, its components, or have other questions. Getting Help If you run into any problems with the images or components, feel free to ask on the centos-devel mailing list. Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.

1 0

Re: [CentOS-devel] [Arm-dev] next steps for altarch with ceph and openstack
by Marcin Juszkiewicz 07 Jul '16

07 Jul '16

W dniu 05.07.2016 o 18:38, George Dunlap pisze: > On 05/07/16 16:49, Marcin Juszkiewicz wrote: >> W dniu 05.07.2016 o 16:28, Jim Perrin pisze: >>> With the work that Marcin has done for openstack on aarch64, as well >>> as the ceph builds, we need to begin working a plan for publishing >>> these builds to a mirror. I'd like to identify the steps needed, and >>> the ownership for those steps. >>> >>> Thomas please correct/update these as needed >> >> Added few people to Cc: from pre-RH summit threads. >> >>> 1. new tag in cbs for aarch64 build, with modified dist for mitaka. >>> Will ceph need this as well? >> >>> 2. If we wish to re-use the centos-release-openstack-mitaka noarch, >>> dependencies of centos-release-ceph-hammer, centos-release-qemu-ev, >>> centos-release-storage-common, and centos-release-virt-common need >>> to be addressed. >> >> It would be good to populate all those repositories. I opened bugs for >> all tags: >> >> https://bugs.centos.org/view.php?id=11084 (openstack) >> https://bugs.centos.org/view.php?id=11085 (ceph) >> https://bugs.centos.org/view.php?id=11086 (virt/kvm-common) > > I looked at this bug, but I couldn't tell exactly what packages you > wanted in here, and why the existing KVM packages weren't sufficient. > Could you just sketch out a brief summary? You are right. I am sometimes still lost in CentOS repository structure. What is in x86-64 virt/kvm-common repository is present in os/ one for aarch64 already. Only qemu-kvm-ev update (2.7.1 -> 2.10.1) would be nice to have. So we can kill that dependency from centos-release-openstack-mitaka package. Added note to the bug (I lack permissions to close it as notabug).

2 1

CentOS PaaS SIG meeting (2016-07-06)
by Troy Dawson 07 Jul '16

07 Jul '16

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays Date: Today Wedensday, 6 July 2016 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms --- openshift-ansible -- Automated testing -- Documentation -- Automated rpm building -- images / image building --- KB will walk us through image building - Open Floor

2 2

CBS users : x509 user certificates expiring policy
by Fabian Arrotin 06 Jul '16

06 Jul '16

Due to some reports in #centos-devel on irc.freenode.net, we thought it would be good to send a reminder at least on this list about the x509 cert/policy for cbs.centos.org : If you have an account on https://accounts.centos.org and are an active builder/developer using https://cbs.centos.org to build pkgs for one or multiple SIGs, it's worth knowing that initially we had the ~6 months validity period for certificates generated through ACO. We documented the "Expired Certificate" error on the dedicated wiki page (see https://wiki.centos.org/HowTos/CommunityBuildSystem?#head-e81bf95796a59cbfd…) but it seems some people forgot about it. So this is just a reminder that you'd have to check if your cert is still valid if you're using cbs.centos.org. On our side, we're working on an automated email reminder that would be sent to people having their certs expired or near expiring date. That way you'll know that you just have to use centos-cert (https://wiki.centos.org/HowTos/CentosPackager) to recreate a new cert (and that step will automatically revoke the previous one) If you have any questions, feel free to discuss this here or in #centos-devel on irc.freenode.net -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

2 3

python-centos-0.1.1-1 Released, centos-packager built for f24 certificate expiration
by Brian Stinson 05 Jul '16

05 Jul '16

Hi Folks, I've released an update to python-centos that fixes an issue when running `centos-cert -v`. The tool will now check the expiration date of your accounts.centos.org user certificate and report it invalid if it's expired. You should find python-centos-0.1.1-1 in CentOS-Extras shortly. I also used this opportunity to publish builds for the centos-packager suite in COPR for Fedora 24, you can find those here: https://copr.fedorainfracloud.org/coprs/bstinson/centos-packager/ If you have any feedback or questions, let us know here. Cheers! -- Brian

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