devel

devel@lists.centos.org

5 participants
4641 discussions

cloud-init in CentOS
by Sam Kottler 02 Dec '14

02 Dec '14

During the cloud instance SIG meeting today we talked about future plans for cloud-init in CentOS. Right now cloud-init is included as part of EPEL and that's where most CentOS users consume it from. The problem is that cloud-init and related bits are critical for building images to run on a public or private cloud, and we need to build early guest initialization tools into the cloud images we produce. Ideally this does not include adding EPEL or packages from EPEL which have not been rebuilt in our build systems. So, the proposal that there's general consensus upon within the SIG is to maintain cloud-init, its dependencies, and any related packages on git.centos.org and rebuild them ourselves. I'm one of the maintainers in EPEL so I offered to maintain the git repos for CentOS, anyone else who would like to be involved in more than welcome to step up. Thoughts, questions, concerns? -s

7 17

Re: [CentOS-devel] [rh-scl] Proposal for CentOS dist-git design
by Honza Horak 01 Dec '14

01 Dec '14

On 11/26/2014 07:51 AM, Remi Collet wrote: > Le 25/11/2014 09:05, Honza Horak a écrit : >> Hi guys, > > Hi, > >> this is a draft for CentOS dist-git design I put together from various >> notes/ideas. It still needs to polish, so it will probably be changing >> in but I wanted to share it as soon as possible to gather feedback soon >> and incorporate your ideas. >> >> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal > > First, sorry for stupid questions, but it seems I still haven't > understand the goal, what we want to fix, and how. Remi, thanks for them! For some I had no answer yet, so I added them to the wiki with some just figured out answer: https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal#FAQ Also CC'ing centos-devel list, since these are all questions we need to answer publicly. So, what we want to fix here.. CentOS is a platform used by huge amount of users, who e.g. develop apps for RHEL. Missing SCLs in CentOS is then problem for those users, because they cannot develop apps using SCLs. I guess there are no doubts SCLs are needed in CentOS. Then, why move *development of the future SCLs* to CentOS and not rebuild RHSCL there downstream? There are RH projects (like OpenShift) that also need to have community version of the product available publicly for all, so they started to use CentOS as their development platform. That means fixes land in git.centos.org first, where everybody can test, and community can see code that will land in RH in the future. So they build community on CentOS. Given there are already projects using CentOS as development platform and given users use CentOS as development platform, we see it as great opportunity to build community around SCLs there as well, which is what SCLs is missing. Also, it makes sense to have a common platform where upstream development of RH layered products takes place and where products may interact. We consider CentOS to be this platform now. > > "... where future upstream development of Software Collections > will take place" > > So, if I understand correctly, if I want to create a "php56" collection, > I should be able to do it in git.centos.org ? Yes. > Where the packages will go (which repository) ? My proposal is to use one repository on CentOS side for all collections. However, this will be a different repository than the one for rebuilt RHSCL collections (if there ever will be such a repository). > How user will see the difference between "stable" packages and > "development" packages ? I'm not sure yet, but there can be two repositories. One repository with stable downstream rebuild of RHSCL, another with SCLs that include fixes above RHSCL and have quality compared to Fedora. > If, at some time, RH provides a "php56" collection, this can be pulled > from this one. But what will happen next to earlier packages ? Nothing, it will stay, new patches will still be landing there before they land in RHSCL. > Will the ACL on the package stay the same ? ACLs were not consulted yet. > About koji setup: > > Which repository/tags will be enabled in each target ? I expect only CentOS and already built SCLs will be available. > Especially, will EPEL be available, or some replacement ? I don't think so, why EPEL? > Will the SCL-SIG be able to add additional packages in existing > collections ? If you mean already released collections, we haven't consulted what will happen with them, just that sources are already available for CentOS and we'll let CentOS community to build them. For new collections, which are subject of this proposal, it will be possible. > Exemple : for now, Fedora is upstream for RHEL, packages are then split > between RHEL and EPEL (short way to describe what happen). > > How can we manage, p.e. php-mcrypt (huge user demand) in this > configuration ? (part of php in Fedora, and php-extras in EPEL). Not sure what are you asking for. php-mcrypt will be part of php56 collection for instance, but I probably did not understand the question. >>From my point of view, there should be a clear definition of "upstream" > > Old: > "Fedora is upstream of RHEL" > New: > git.centos.org is upstream of RHSCL, > in one "experimental" repository > (not yet in RHSCL) Yes. > Old: > "RHEL is upstream of CentOS" > New: > git.centos.org receive clone copy of RH content > in one "production" repository. > (clone of RHSCL) > > git.centos.org produce more content > in one "additional" repository > (like EPEL for RHEL) Yeah, the whole point is that CentOS won't be only downstream for all RH products any longer. It will stay downstream for RHEL, but upstream for some other projects. > I think we probably even need more git or more branches, not a single one) Git will be similar to what we have internally, one repository per component and branch for every "combination of CentOS and collection" where it makes sense. But it is already mentioned in the proposal. > > Regards, > Remi. > > > > P.S. are we trying to kill Fedora ? I hope not :) Just SCLs don't bring so much value for Fedora users, since they already have their packages in latest versions there. That does not mean SCLs are not usable there, I'd love to see SCLs in Fedora still; just we focus more on CentOS now because it will solve more issues for more users currently. Honza

2 2

[PATCH] Some packages seem to want to know where 'topdir' is....
by Pat Riehecky 01 Dec '14

01 Dec '14

From: Pat Riehecky <riehecky(a)fnal.gov> --- return_disttag.sh | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/return_disttag.sh b/return_disttag.sh index 2c1e522..0048cd6 100755 --- a/return_disttag.sh +++ b/return_disttag.sh @@ -25,12 +25,12 @@ build_with_dist_scl() { SCL=${3:-} if [[ "x${SCL}" == 'x' ]]; then - result=$(rpm --define "dist ${DIST}" -q --specfile "${SPECFILE}" --qf '%{n}-%{v}-%{r}\n' 2>/dev/null | head -n 1) + result=$(rpm --define "%_topdir `pwd`" --define "dist ${DIST}" -q --specfile "${SPECFILE}" --qf '%{n}-%{v}-%{r}\n' 2>/dev/null | head -n 1) else - result=$(rpm --define "dist ${DIST}" --define "scl ${SCL}" -q --specfile "${SPECFILE}" --qf '%{n}-%{v}-%{r}\n' 2>/dev/null | head -n 1) + result=$(rpm --define "%_topdir `pwd`" --define "dist ${DIST}" --define "scl ${SCL}" -q --specfile "${SPECFILE}" --qf '%{n}-%{v}-%{r}\n' 2>/dev/null | head -n 1) fi - echo $result + echo ${result} } ##################################################################### -- 1.7.1

2 1

CBS/Infra Meeting 01-Dec-2014 14:00 UTC
by Brian Stinson 01 Dec '14

01 Dec '14

Greetings All! Every week we get together to talk about the status of the CentOS Community Build System[1]. We will be meeting on 01-Dec-2014 at 14:00 UTC in #centos-devel on freenode. Agenda: #info Topic: Status Updates #info Subtopic: Centralized Authentication #info Subtopic: Koji/Repos #info Subtopic: Centpkg #info Topic: SCL dist-git Proposal #info Topic: Open Floor Cheers! Brian [1] http://cbs.centos.org/

2 1

Proposal for a bi-weekly Storage SIG meeting
by Lalatendu Mohanty 28 Nov '14

28 Nov '14

Hi All, Lets meet at 15:00 UTC, Wednesday or Friday bi-weekly in #centos-devel for Storage SIG [1]. Does this time i.e. 15:00 UTC work for you? yes/no/suggestion? Which day works better for you? Wednesday or Friday? Agenda might be something like this: #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic:OpenAFS #info Subtopic: Ceph #info Topic: Open Floor [1] http://wiki.centos.org/SpecialInterestGroup/Storage Thanks, Lala #lalatenduM

3 4

Proposal for CentOS dist-git design
by Honza Horak 28 Nov '14

28 Nov '14

Hi guys, this is related to the new SCL SIG [1], which is supposed to bring SCL development into CentOS, which is supposed to become upstream for Software Collections. I've promised I'd look at how dist-git could look like on CentOS side, since we want to start keeping source code for SCLs under CentOS soon. So, [2] is a proposal -- please, take a look at it, so we have something to start with. Let's see if it is feasible. We can also move it to CentOS wiki, which would be more appropriate place for it, but I cannot figure out a where I have permissions to add some new content to. More information about Software Collections concepts is available at [3]. What next? I think we should gather some feedback on this proposal, try to figure out open questions there. Then we will pick up some software collection and create some PoC build from CentOS dist-git. Regards, Honza [1] http://wiki.centos.org/SpecialInterestGroup/SCLo [2] https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal [3] https://www.softwarecollections.org/en/docs/guide/

3 4

Fwd: Open Seat on the Fedora Server Working Group
by Karsten Wade 25 Nov '14

25 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a heads up for anyone interested in being involved in the upstream that is essentially the future of CentOS Linux core. Much if it is now being described and directed by the Fedora Server Working Group. You can read more about the working group's objectives here: https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Product… For the open seat, you can self-nominate even if you are new to the Fedora Project. However, you might find it just useful to watch and comment on the working group's activities. They run open IRC meetings and discussions. Either way, it's an opportunity to learn about and help shape the future of the Red Hat Linux distro family. - -------- Forwarded Message -------- Subject: Open Seat on the Fedora Server Working Group Date: Tue, 25 Nov 2014 14:11:19 -0500 From: Stephen Gallagher <sgallagh(a)redhat.com> Reply-To: devel(a)lists.fedoraproject.org To: Server SIG <server(a)lists.fedoraproject.org>, devel-announce(a)lists.fedoraproject.org This past week, David Strauss chose to step down from his position on the Fedora Server Working Group, citing a lack of alignment with his current work usage. The Fedora Server SIG would like to thank David for his contributions up to this point and wish him well. This means that there is currently a vacancy in the Fedora Server Working Group. The Working Group is the nine-person volunteer body that oversees the development, testing, release, documentation, marketing and evangelism of the Fedora Server. Membership on this Working Group is a moderate commitment requiring a participation of a minimum of two hours a week, one hour of which being the (usually) weekly meeting. Membership on the Fedora Server Working Group does not require you to be a developer, tester or administrator. Anyone who is interested in advancing any of the Fedora Server's goals[2] is eligible to self-nominate. Document-writers, translators, Fedora Ambassadors, end-users and anyone else can become a part of this team. If you feel that you are interested in becoming more involved with the Fedora Server, we encourage you to self-nominate by joining the Fedora Server mailing list[1] and sending a self-introduction and nomination email to that list. We will have open nominations from now until Tuesday, December 9th, where we will vote on the new member at the weekly meeting. If you self-nominate but aren't selected to serve on the Working Group, do not fret! The Server SIG is open to all and the Working Group will always listen to your advice and concerns, so please stick around! While the Working Group is the final authority and voting body when disagreements come up or official decisions (like branding) need to be made, we are not the only people working on the Fedora Server. The Server SIG is small today, but growing. We would very much like to have you join us. [1] https://admin.fedoraproject.org/mailman/listinfo/server [2] https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Product… - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlR01wQACgkQ2ZIOBq0ODEHcJQCfWYO1fIzBhYXb6cec7PpeAxxr gKkAnjVn2kh20zqfaHEaup1HA0URzEE4 =fXmU -----END PGP SIGNATURE-----

1 0

CentOS Linux release 7.0.1406 (Core) - driver via_velocity
by Marcelo Barbosa 25 Nov '14

25 Nov '14

Hi everybody, I have some servers running CentOS 6.5 with network driver "via_velocity", but in new CentOS release (7.0.1406) this driver not present, more informations bellow: # modprobe via_velocity modprobe: FATAL: Module via_velocity not found. # lspci -v 04:08.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Device 0110 Flags: 66MHz, medium devsel, IRQ 11 I/O ports at e300 [disabled] [size=256] Memory at f0403000 (32-bit, non-prefetchable) [disabled] [size=256] Capabilities: [50] Power Management version 2 04:09.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Device 0110 Flags: 66MHz, medium devsel, IRQ 11 I/O ports at e200 [disabled] [size=256] Memory at f0402000 (32-bit, non-prefetchable) [disabled] [size=256] Capabilities: [50] Power Management version 2 04:0a.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Device 0110 Flags: 66MHz, medium devsel, IRQ 10 I/O ports at e100 [disabled] [size=256] Memory at f0401000 (32-bit, non-prefetchable) [disabled] [size=256] Capabilities: [50] Power Management version 2 04:0b.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Device 0110 Flags: 66MHz, medium devsel, IRQ 10 I/O ports at e000 [disabled] [size=256] Memory at f0400000 (32-bit, non-prefetchable) [disabled] [size=256] Capabilities: [50] Power Management version 2 Sugestions ? Cheers, firemanxbr

4 9

Re: [CentOS-devel] epel-7-ppc64
by youbest＠sina.com 25 Nov '14

25 Nov '14

Hi, Karanbir Singh I'm sorry, I don't quite understand what you mean, I did not rely on specific RHEL resources in the whole building process. Source code using CentOS 7.0.1406 provides, At http://vault.centos.org/7.0.1406/os/Source/SPackages/ (http://95.211.98.141/centos/ should be a mirror like), and a small amount from RHEL 7 for the PPC package source code. ----- Original Message ----- From: Karanbir Singh <mail-lists(a)karan.org> To: centos-devel(a)centos.org Subject: Re: [CentOS-devel] epel-7-ppc64 Date: 2014-11-24 18:24 On 24/11/14 09:34, youbest(a)sina.com wrote: > Hi, All > My name is Sun Haiyong, you can call me "Haiyong", I recommend a > CentOS code based on PPC64 (Big Endian) Install-system and software > repository: > (Install-DVD ISO) > http://mirror.lemote.com/CPOS/images/CPOS-7-Installation-20141120-1.iso > (software repository) http://mirror.lemote.com/CPOS/os/ > I am reasonabally sure that this wasent bootstrapped from publicly available sources, this is built on RHEL7 itself. Can you confirm ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org http://lists.centos.org/mailman/listinfo/centos-devel

2 1

Last week's CentOS Atomic SIG minutes + reminder - no meeting this week!
by Joe Brockmeier 24 Nov '14

24 Nov '14

You can find the meeting minutes from last week here: http://centos.org/minutes/2014/november/centos-devel.2014-11-18-15.34.html Because this is a holiday week in the U.S. and a lot of folks will be traveling early ahead of Thanksgiving, we decided to skip tomorrow's meeting. Next SIG meeting will be Tuesday 2 December. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

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