devel July 2016

devel@lists.centos.org

36 participants
39 discussions

glibc build fails on disk >2TB
by Captain Wiggum 21 Jul '16

21 Jul '16

We are rebuilding the centos 6.8 src.rpm's for both 64-bit (.x86_64.rpm) and also 32-bit-compat (.i686.rpm) When making 32-bit compatible build on a disk >2TB, the build will fail because or large inodes: /home/mlos/WORK/os/PACKAGES/glibc/WORK/BUILD/glibc-2.12-2-gc4ccff1/build-i686-linuxnptl/elf/sln /home/mlos/WORK/os/PACKAGES/glibc/WORK/BUILD/glibc-2.12-2-gc4ccff1/build-i686-linuxnptl/elf/symlink.list /home/mlos/WORK/os/PACKAGES/glibc/WORK/glibc-root/lib/ld-linux.so.2: invalid destination: Value too large for defined data type The solution is to add "-D_FILE_OFFSET_BITS=64" and this has fixed the issue on glibc and all our other i686 RPM builds. However, with the latest update glibc-2.12-1.192.el6.src.rpm we find adding the above flag will cause the following error: In file included from ftello.c:29: ../include/stdio.h:151: warning: asm declaration ignored due to conflict with previous rename ftello.c:66: error: '__EI_ftello' aliased to undefined symbol '__GI_ftello' make[3]: *** [/home/mlos/WORK/os/PACKAGES/glibc/WORK/BUILD/glibc-2.12-2-gc4ccff1/build-i686-linuxnptl/libio/ftello.os] Error 1 Has anyone else hit this issue? Any tips appreciated.

2 2

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

20 Jul '16

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays Date: Today Wedensday, 20 July 2016 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms --- origin 1.2.1 released as a security update --- openshift-ansible-3.2.13 now installable from testing --- This one should have all the changes we need, will be testing to go to release -- Documentation -- Automated testing -- images / image building --- Working on getting Dockerfile.centos7 and .cccp files in origin ---- https://github.com/openshift/origin/pull/9864 - Open Floor

1 0

[Cloud SIG] CentOS Cloud SIG meeting, Thursday, 15:00 UTC
by Rich Bowen 19 Jul '16

19 Jul '16

A reminder that we hold the CentOS Cloud SIG meeting each week on #centos-devel, on the Freenode IRC network, Thursdays at 15:00 UTC. The agenda for this meeting may be found here: https://etherpad.openstack.org/p/centos-cloud-sig We welcome everyone to attend this meeting, where we discuss open source cloud infrastructure platforms packaged for CentOS Thanks! -- Rich Bowen - rbowen(a)redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity

1 0

Atomic Developer Bundle 2.2.2 released
by Lalatendu Mohanty 19 Jul '16

19 Jul '16

We have released the Atomic Developer Bundle 2..2.2 through CentOS Atomic SIG. ADB consists of a Vagrantbox and couple of Vagrant plugins. Please refer project documentation for more information [4]. The ADB release also includes release of following ecosystem projects: * vagrant-service-manager1.2.0 : A set of utility scripts and configuration files for ADB This release adds several bug fixes and enhancements , including: * docker version got updated to docker-1.10.3. * ADB YUM repo now include AtomicApp. So "yum install atomicapp" will install AtomicApp [5]. * vagrant-service-manager can now download client binaries for docker, OpenShift i.e. OC binary. This is a very useful feature as users can use docker and OpenShift services from the workstation without login in to the guest Vagrant box. This release also includes many changes and bug fixes, which are detailed in the release change log of vagrant-service-manager [1] and ADB [2]. Introduction: Atomic Developer Environment (ADB) helps to setup Kubernetes, Docker, OpenShift, Mesos Marathon on your workstation easily. Application developers can quickly create the setup to containerize applications and run them using mentioned platforms . ADB is designed to run on Microsoft Windows, OS X and on GNU/Linux and give homogeneous setup across different operating systems. ADB and OpenShift can also be used directly from Eclipse using docker tooling and OpenShift adapter [6] [7]. Please update the ADB Vagrant box [3] and the vagrant-service-manager ($ vagrant plugin update vagrant-service-manager) and give the new ADB version a spin. [1] https://github.com/projectatomic/vagrant-service-manager/releases/tag/v1.2.0 [2] https://github.com/projectatomic/adb-atomic-developer-bundle/releases/tag/v… [3] https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/do… [4] https://github.com/projectatomic/adb-atomic-developer-bundle [5] https://github.com/projectatomic/atomicapp [6] https://developers.openshift.com/getting-started/eclipse.html [7] https://www.eclipse.org/community/eclipse_newsletter/2015/june/article3.php Thanks, Lala

1 0

Atomic Developer Bundle 2.2.2 released
by Lalatendu Mohanty 19 Jul '16

19 Jul '16

1 0

[PAAS SIG] origin 1.2.1 is available in testing
by Troy Dawson 18 Jul '16

18 Jul '16

Hello, Origin v1.2.1 has been released, containing a security hot fix to the server components to prevent some users from escalating privileges via the API. I have created a 1.2.1 rpm for Centos. It is currently in centos-openshift-origin-testing. It has passed all of my tests but I'd feel more comfortable if others tested it as well. If you already have centos-release-openshift-origin installed, you can update and test this rpm via yum --enablerepo=centos-openshift-origin-testing update origin\* For those that want to download the source rpm, it is here. http://cbs.centos.org/kojifiles/packages/origin/1.2.1/1.el7/src/origin-1.2.… I plan to push this to release on Monday or Tuesday (July 18 or 19) so test as soon as possible. Thanks Troy Dawson

1 1

unsubscribe
by Regis Perdreau 16 Jul '16

16 Jul '16

2016-07-12 16:36 GMT+02:00 Haïkel <hguemar(a)fedoraproject.org>: > 2016-07-12 9:10 GMT+02:00 Fabian Arrotin <arrfab(a)centos.org>: >> I just had a look at CBS and was wondering how one SIG (so not >> ConfigMgmt SIG specific, but let's use that as an example) can interact >> with other SIGs. >> >> One example is Ansible : it seems some other SIGs are relying on it and >> so actually the ConfigMgmgt SIG isn't able to build it as it's already >> built with the same ENVR but in a different target/tag : >> https://cbs.centos.org/koji/packageinfo?packageID=1947 >> >> What would be the option for this ? >> Actually the direct option is for the ConfigMgmt SIG to just tag that >> build (for example for ansible-2.1.0.0-1.el7) so that it will appear in >> the correct repositories, but I'm wondering if such SIG wouldn't have to >> be considered "authoritative" and so having to discuss/bump/build new >> releases, and then other SIGs can just consume/tag a specific build/ENVR >> they want in their own repositories. >> >> -- >> Fabian Arrotin >> The CentOS Project | http://www.centos.org >> gpg key: 56BEC54E | twitter: @arrfab >> > > Concerning Cloud SIG, we're relying on two packages that are Cfg Mgmt > SIG-related: > * Puppet: puppet is quite critical for us, as it's the heart of our > installers (packstack, TripleO), > critical component for our CI and also upstream CI. > We also had to patch Puppet3 default for buggy Puppet behaviours (like > not supporting provides), I co-maintain the Fedora package with the > help of Red Hat puppet experts. > Our puppet package is mere rebuild of Fedora Rawhide (with a decent > amount of CI/testing before being shipped) > * Ansible: It's more and more used in our infrastructure, WeiRDO our > CI swiss-knife relies on it. We're currently not shipping it but we'll > likely have too. > > I don't mind handing puppet packaging to Cfg Mgmt as authoritative > source, nor Ansible, I think we can manage to work together. > What worries me is that CfgMgmt SIG used to think about relying on > Software Collections, that we're not ready to use in the Cloud SIG. > > Regards, > H. > >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel(a)centos.org >> https://lists.centos.org/mailman/listinfo/centos-devel >> > _______________________________________________ > CentOS-devel mailing list > CentOS-devel(a)centos.org > https://lists.centos.org/mailman/listinfo/centos-devel

1 0

Question about authoritative SIG for specific pkg[s] (wrt ConfigMgmt SIG)
by Fabian Arrotin 15 Jul '16

15 Jul '16

I just had a look at CBS and was wondering how one SIG (so not ConfigMgmt SIG specific, but let's use that as an example) can interact with other SIGs. One example is Ansible : it seems some other SIGs are relying on it and so actually the ConfigMgmgt SIG isn't able to build it as it's already built with the same ENVR but in a different target/tag : https://cbs.centos.org/koji/packageinfo?packageID=1947 What would be the option for this ? Actually the direct option is for the ConfigMgmt SIG to just tag that build (for example for ansible-2.1.0.0-1.el7) so that it will appear in the correct repositories, but I'm wondering if such SIG wouldn't have to be considered "authoritative" and so having to discuss/bump/build new releases, and then other SIGs can just consume/tag a specific build/ENVR they want in their own repositories. -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

4 5

Re: [CentOS-devel] ConfigMgmt SIG Status
by Ben Hosmer 15 Jul '16

15 Jul '16

I'm having a hard time getting my bearings. Where can I help out?

4 3

Update on the CentOS Community Container Pipeline
by Karanbir Singh 14 Jul '16

14 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The last week and a half, the dev team split up and took on specific focus areas. The aim being to spend a few days and quantify the technical debt and also validate the features we had already delivered ( or had hoped to have delivered ). This allowed us to run a sort of retrospective sprint. The result of which was checklists that allow us to measure a state of completeness in the following areas : - - Post-build and regular image scanning + reporting - - Ability for a contributor to onramp rapidly - - Production band-aid's / flaky code that needed immediate attention - - Ensuring we've completed the initial set of user stories we'd set out to deliver on. Over the next 2 weeks, our aim is going to be to try and close down as much of this debt as we can, before moving back to focusing on Feature development. We've also started handing off SRE roles and developing a deployment pipeline to move towards a CD model in the coming weeks. As we move towards production with the SRE / Dev splits, there will be some code work that we need to work on, and we will try to track that via a priority task list, labelled as 'bugs/issues'. In order to better organise the tasks, we've created 5 labels as follows : - - Contributor Process / Developer enablement - - Service Feature - - User - - Scanner + Testing - - Production Critical We've also agreed, and reminded ourselves, to not work on things that are not on cards and in the current sprint. And we've agreed to run daily standups at 10:00 UTC daily. - -- Karanbir Singh, Project Lead, The CentOS Project, London, UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXh7EvAAoJEI3Oi2Mx7xbtXIwH/2Mb2P3GFJXaTkI1BEgoqLe1 LIFqp0G1kJYx+7FNlxjLgo1YXoWVw0gMtEgSz9dDyx4ON/MDhSHKWLILzGMwqqoK kCmkSiL5eSpVedQrh3CFf6/OqfDi4NXTIz0a2VB8SvFxlBpNEl4UZr5eX9+U8HI2 jxCZtNjB0TOaL0m4k9rxtrs75QCr1t5aiFbcDbhyV7WDfAU3xlmGfaOBojofrLHD J43a4VZ9/TyK0gmuH7/bZ9qZq4j7dDHC3AZwBaUtY0pRzrtRwpm3gDmpuKxaas8M sbVbwYLPauWtbVOsqHvE3hCDbPd6tUR+pTELW+f28V2gR5Sbe/bOQ9gTfh8/0l8= =alEJ -----END PGP SIGNATURE-----

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel July 2016