devel

devel@lists.centos.org

7 participants
4671 discussions

[Cloud SIG] weekly meeting
by Rich Bowen 26 Jan '16

26 Jan '16

The Cloud SIG holds its weekly meeting on Thursdays at 15:00 UTC in #centos-devel on Freenode. It has become evident that this isn't a great time. Turnout is very poor, and many of the folks that want to come, have conflicts almost every week. I was wondering if I could get a show of hands of who would like to be attending that meeting, so that we can get some idea of the distribution of time zones, and see if we can find a better time. Thanks. -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://rdoproject.org/

3 3

[Storage SIG] Ceph build target and tags: +1s required
by François Cami 26 Jan '16

26 Jan '16

Hi, The Ceph project needs build targets and tags for Ceph Hammer in cbs. We would like to use upstream release names (Hammer, Infernalis...) instead of versions ( http://docs.ceph.com/docs/master/releases/ [^] ). Repositories are at: https://github.com/CentOS-Storage-SIG/ceph https://github.com/CentOS-Storage-SIG/ceph-deploy The relevant Hammer git branch is currently sig-storage7-ceph-hammer. So I believe the cbs build target should be: storage7-ceph-hammer-el7 and tags: storage7-ceph-hammer-{candidate,testing,release} Karanbir, Lalatendu, Patrick, Niels, Brian, Lincoln, could you please validate the naming scheme, and then add +1s as requested by Thomas at: https://bugs.centos.org/view.php?id=10244 François

2 1

Self Introduction: tdawson
by Troy Dawson 25 Jan '16

25 Jan '16

Hi, My name is Troy Dawson. I've been working on the OpenShift project for over 4 years. Before that I was one of the main developers of Scientific Linux. I've been a Fedora packages for several years as well. I'd like to get OpenShift Origin into CentOS, as rpm's and docker images. Troy Dawson

1 0

Building powerpc-utils from git.centos.org
by Vit Ry 22 Jan '16

22 Jan '16

Hi all. I am trying to build powerpc-utils[1] on ppc64, but build fails with error: ... checking whether the linker accepts -pie... yes checking that generated files are newer than configure... done configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile config.status: creating powerpc-utils.spec config.status: executing depfiles commands Makefile:864: *** multiple target patterns. Stop. RPM build errors: ... as I investigate, the reason is SOURCES / powerpc-utils-1.2.15-man.patch [2] with line + man/lsprop.8:q \ I propose to fix it like s/lsprop.8:q/lsprop.8/ [1]: https://git.centos.org/summary/rpms!powerpc-utils [2]: https://git.centos.org/blob/rpms!powerpc-utils/262646878310d3ffa9acd72b995f… --- Regards, Vit Ry.

2 3

3.18.22 Kernel RPM Contribution to CentOS
by gayathri.madda＠wipro.com 19 Jan '16

19 Jan '16

Hi Team, As there was no official Linux kernel RPM (version 3.18.22) for CentOS 7 in any of their distribution versions, we have customized spec file for creating 3.18.22 kernel RPM for CentOS-7 Minimal version by taking 3.18.12 kernel spec file STEPS for Generating Kernel RPM 1. Downloaded the latest 3.18.22 kernel source code "linux-3.18.22.tar.gz<https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.22.tar.gz>" from https://www.kernel.org/pub/linux/kernel/v3.x/ 2. Customized the 3.18.12 kernel spec file w.r.t 3.18.22 kernel SPEC and created RPM for CentOS 7 Minimal Version Regards, Gayathri The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

4 3

Use of PTPd on CentOS 6
by Claudio Scordino 19 Jan '16

19 Jan '16

I need to create a reliable and accurate synchronization between two CentOS 6 machines connected through a direct Ethernet connection. I've seen that on Linux several implementation of the IEEE 1588 Precision Time Protocol (PTP) <https://en.wikipedia.org/wiki/Precision_Time_Protocol> exist: - PTPd <http://ptpd.sourceforge.net>: - Apparently, this is the original implentation - Apparently, it is still maintained <http://www.github.com/ptpd/ptpd> - PTPd2 <http://ptpd2.sourceforge.net>: - A new version meant to supersede the previous implementation - Apparently unmaintained - For CentOS 6, available only in the EPEL repositories - PTPv2d <http://code.google.com/p/ptpv2d>: - A further implementation - Unmaintained as well - linuxptp <http://linuxptp.sourceforge.net>: - A specific implementation for Linux - Maintained - Available on the CentOS repositories - Suggested by the RedHat documentation for both RedHat 6 <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/ht…> and RedHat 7 <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht…> My questions follow: - Why does the RedHat documentation suggest the use of linuxptp <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/ht…> for RedHat 6 (based on Linux kernel 2.6) despite the linuxptp documentation says that a Linux kernel version 3.0 or newer is needed <http://linuxptp.sourceforge.net/> ? - Which are differences between PTPd2 and Linuxptp in terms of reliability and timing accuracy ? - Which one should I prefer on CentOS 6 and on CentOS 7, respectively ? - Why either PTPd2 and Linuxptp do not synchronize immediately and often need me to start/stop the service several times or manually change system time through date to make the machine synchronize ? Many thanks for any hint.

2 1

Introduction for SCLo SIG and PHP package - remi
by Remi Collet 19 Jan '16

19 Jan '16

Howdy, CentOS account (FAS) : remi PHP packages maintainer in various places. Goal: I'd like to build various additional packages for the various PHP SCL which are not available in upstream RHSCL. Those packages will use "sclo-php5#" prefix, but are really part of the (rh-)php5# collection, different prefix used to avoid user confusion. Notice: most of those, are already built in 'morephp5#' community repository. So I need CBS access to be able to build them. Remi.

1 1

Re: [CentOS-devel] 3.18.22 Kernel RPM Contribution to CentOS
by gayathri.madda＠wipro.com 19 Jan '16

19 Jan '16

Re-Sending the Mail .. Regards, Gayathri.M From: Gayathri Madda (WT01 - Digital Marketing) Sent: Tuesday, January 19, 2016 2:27 PM To: 'centos-devel(a)centos.org' <centos-devel(a)centos.org> Subject: 3.18.22 Kernel RPM Contribution to CentOS Hi Team, As there was no official Linux kernel RPM (version 3.18.22) for CentOS 7 in any of their distribution versions, we have customized spec file for creating 3.18.22 kernel RPM for CentOS-7 Minimal version by taking 3.18.12 kernel spec file STEPS for Generating Kernel RPM 1. Downloaded the latest 3.18.22 kernel source code "linux-3.18.22.tar.gz<https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.22.tar.gz>" from https://www.kernel.org/pub/linux/kernel/v3.x/ 2. Customized the 3.18.12 kernel spec file w.r.t 3.18.22 kernel SPEC and created RPM for CentOS 7 Minimal Version Regards, Gayathri The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13)
by Honza Horak 18 Jan '16

18 Jan '16

SCLo SIG meeting will be today at 16:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * devtoolset-4 rebuilding updates https://bugs.centos.org/view.php?id=10106 * review of how development of new scls is working rought proposal: building packages -> candidate -> sanity testing -> testing -> [wait till rhscl is released] -> tag released -> sign&release * Provides/Obsoletes to centos-release-scl * package for RHEL users that installs sclo packages above RHSCL Honza

2 2

Re: [CentOS-devel] [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13)
by Honza Horak 18 Jan '16

18 Jan '16

On 01/14/2016 07:35 AM, Nick Coghlan wrote: > On Thu, Jan 14, 2016 at 3:33 AM, Honza Horak <hhorak(a)redhat.com> wrote: >> #topic review of how development of new scls is working >> rought proposal: building packages -> candidate -> sanity testing -> >> testing -> [wait till rhscl is released] -> tag released -> sign&release >> - usual tagging process: tag -candidate -> [sanity testing] -> tag >> -testing -> [better testing] -> tag -released -> sign&release >> - how it will be done for collections that gonna be released in RHSCL in >> the future? >> - idea: such collections should stay in -testing until they are released >> in RHSCL -- bad idea? shout now. > > What's the scope of discussion here in terms of "sclo-*" SCLs and "rh-*" SCLs? > > For "sclo-*" SCLs, I'd expect the RHSCL release cycle to be entirely irrelevant. Yes, they may be theoretically influence in cases the sclo-* SCLs depend on some rh-* SCLs -- in that case their release is depended on RHSCL. > For "rh-*" SCLs, having them remain in -testing until the downstream > release (so they become generally available to RHEL & CentOS users at > the same time) seems reasonable. > > So if someone wanted to take an existing rh-* package and turn it into > an sclo-* package that could be updated independently of the RHSCL > release cycle, they'd be free to do that. Yes, in case someone would like to include different set of packages or deliver different version, then it effectively become a new SCL, that needs to be treated that way. Honza

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel