January 2014 - devel - lists.centos.org

Cloud Instance SIG and Vendor ecosystems
by Karanbir Singh 23 Jan '14

23 Jan '14

hi, I'd like to ask everyone for comments on and around working with vendor Ecosystems. We already have relationships in place ( some as old as 4 - 5 years ) where we have worked with vendors to get CentOS images into their service plans; but going forward we should consider what the overall goal here is going to be. Some vendors are easier than others to work with, but is this something we should persue as a part of the CentOS Instance SIG ? I am quite keen to build on the existing relationships with people like AWS, GCE, HPCloud, BrightBox etc and even expand the scope of the vendor involvement in the SIG, but where is everyone else's thought process on this ? - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 3

github foo
by Karanbir Singh 21 Jan '14

21 Jan '14

hi, It would be great if Merge Requests from github.com could be announced on irc #centos-devel in realtime, and a summary of all requests from the day posted to this centos-devel list at midnight UTC. Is something like that possible ? And if so, how does one go about setting that up. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 1

Building c6.99.00
by Karanbir Singh 18 Jan '14

18 Jan '14

hi, First community contributed build request for the el7b1 distro! : https://github.com/CentOS/sig-core-bld-seven/pull/1 We're going to build the entire rhel7b1 srpm stock against f19-i686 + rolling build repos into target c6.99.00-i686. Once we have that done, we remove the f19 requirement and rebuild against c6.99.00-i686 into c6.99.01-i686 rolling builds. That should give us a good idea of where things are w.r.t i686. We can then check back into what is needed into the x86_64 tree for multilib, and list the rest of the distro. Once we have that, I'd like to start a conversation around what is needed and how people feel about 'owning' the i686 that isnt needed for multilib x86_64. For now, the churn will start, build logs are going to the centos-build-reports list ( http://lists.centos.org/pipermail/centos-build-reports ) This is what a success report looks like http://lists.centos.org/pipermail/centos-build-reports/2014-January/000005.… the build-id is timestamp to a second's resolution. For centos6 one of the key things we've had to do ( increasingly lesser of ) is to rewind the buildroot states ( aka. git blame, but for the entire distro as a whole ) and patch blame ( aka git blame, for the spec file, rewinding patch layers ). The Build-ID is key to that process. Based on initial builds, we are not going to need any of this anymore ( we've not used it in el6 since the 6.3+updates days ). Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 1

Re: [CentOS-devel] Repository structures for SIG and variants in the future
by Mike McLean 17 Jan '14

17 Jan '14

On Fri, Jan 17, 2014 at 12:06 PM, Jim Perrin <jperrin(a)centos.org> wrote: > On 01/17/2014 10:06 AM, Ljubomir Ljubojevic wrote: > > So how do you intend to solve this without priorities? Especially if > > there is a need for some packages to be compiled with different flags? > > Ideally by eliminating package duplication for the SIG/repos who work > with us, but that's an ivory tower goal that's likely unattainable. > We certainly want to reduce it and box it in. It's clear that we do want to allow overlap, but we need to try to build some sanity into it and avoid it when it is not truly necessary > It will likely be a combination of working with SIGs to coordinate and > cooperate, changing to SCL builds where possible and appropriate, and > documentation to better educate the users. > > SCL builds provide a nice name-spaced way to have multiple versions of > the same packages installed. For example, python27, python33, multiple > php and httpd versions, etc. All of which are mostly impractical with > the older rpm packaging style (see php and httpd for example). This is > by no means a silver bullet, but it does solve a fair chunk of the issue. > Agreed. SCLs are a natural fit here Without SCLs, the SIG will actually be overriding the base package. There are a host of potential problems here, repo priority is the least of it. For major significant changes this could spiral into a dependency nightmare, or simply break things in the base distro. For minor changes (small change, bump release), the such issues would be less likely. For overriding with higher versions, the repo priority plugin would be unnecessary. For release bumps, the SIG would have to track the base closely to stay ahead (granted they should probably do that anyway). At any rate my point is that there are many different reasons to do this and many different ways it which it might be done. Some approaches will be sane, and others very, very unwise. I suspect that we'll wind up with a fairly long policy document delineating these different cases, stating what is allowed, and listing best practices.

1 0

Documentation SIG
by Zachary Oglesby 17 Jan '14

17 Jan '14

> On 01/10/2014 05:22 PM, Philip Mather wrote: >> Has there been any interest or progress in the suggested Documentation SIG? >> > > Is this proposal to 'write more docs' or > > Is it more of a religious 'everyone should write more docs, we will create resources, make it easier' etc ? > > step1, lets define the problem :) > > - K Having worked on Fedora Docs for many years I would like to make a suggestion that the same model is followed, just in reverse. Many Red Hat docs start as Fedora Documentation and are tweaked to fit RH products. CentOS can use the RH docs as a base and remove the unneeded content. While it will not provide everything CentOS needs for documentation a lot of good content has already been written as in licensed so that it can be reused (CC BY-SA 3.0). I may be making an incorrect assumption, but it is worth mentioning.

4 3

Repositories, Packaging and challenges for rpms for the SIGs
by Karanbir Singh 17 Jan '14

17 Jan '14

hi guys the next OfficeHours on the 20th Jan is going to be around packaging, rpms and how we might handle this moving forward. The EPEL as default deps ? can packages overlap with base ? what sort of testing we permit ? what is 'required', what is 'optional', how can we use SCL's etc. James and Mike will be with us, so we can even delve into yum side issues and build side issues that arise for whatever policies are proposed. http://wiki.centos.org/OfficeHours for date and details. The panel will take questions from people on irc, twitter and on the q&a session on the hangout itself. Regards - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 2

EL7 build packages and http://seven.centos.org/
by Pat Riehecky 17 Jan '14

17 Jan '14

Per: http://seven.centos.org/2014/01/state-of-the-build-20140104/ I've got a bunch of BZs opened upstream (by me and others) that may help clarify the build problems you've hit: args4j-2.0.16-11.el7.src.rpm : 1049615 at-3.1.13-12.el7.src.rpm : 1044707 dapl-2.0.34-1.el7.src.rpm : 1044727 esc-1.1.0-25.el7.src.rpm : 865721 libbase-1.1.3-8.el7.src.rpm : 1038176 istack-commons-2.17-2.el7.src.rpm : 1049582 jboss-ejb-3.1-api-1.0.2-7.el7.src.rpm : 1029971 jboss-interceptors-1.1-api-1.0.2-0.6.20120319git49a904.el7.src.rpm : 1029974 jboss-jaxrpc-1.1-api-1.0.1-4.el7.src.rpm : 1029975 jboss-servlet-3.0-api-1.0.1-6.el7.src.rpm : 1029976 jboss-transaction-1.1-api-1.0.1-5.el7.src.rpm : 1029979 tomcat-7.0.40-2.el7.src.rpm : 1038183 pyliblzma-0.5.3-8.el7.src.rpm : 1044625 zsh-5.0.2-3.el7.src.rpm : 1034754 / 1037828 --- I was able to compile: apache-commons-net-3.2-7.el7.src.rpm boost-1.53.0-14.el7.src.rpm cdi-api-1.0-9.SP4.el7.src.rpm fftw-3.3.3-6.el7.src.rpm json-c-0.11-1.el7.src.rpm jsr-311-1.1.1-4.el7.src.rpm stax-ex-1.7.1-4.el7.src.rpm These builds are 100% untested and my mock logs haven't been reviewed in any way. But they are a hint as to how we got them built. Yours if you want them, 1.3Mb tar.bz2 archive for all of them. As for the rest, I suspect 1049615 applies to more than a few others. The maven world changed a bit between here and Fedora -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/

5 9

Differences in IaaS and PaaS, thoughts for the Cloud SIG
by Adam Miller 16 Jan '14

16 Jan '14

Hello all, I would like to start a discussion around the relationship between IaaS and PaaS as topics for the CentOS Cloud SIG. Should we have one SIG with "sub-SIGs"? Separate SIGs for each? or some other variation? A little background, I'm a member of the OpenShift team at Red Hat and we work heavily on OpenShift Origin[0] which is our upstream project. We've in the past focused on RHEL and Fedora as our primary development platforms. With the recently announced partnership with CentOS, we're all looking forward to working with the CentOS community and making OpenShift Origin, the open source Platform as a Service (PaaS) offering, available on CentOS and collaborating with the community around the platform. We would like to pair our upstream code base with a community-centric distribution featuring an Enterprise Linux release cadence making CentOS + OpenShift Origin a natural fit for community members seeking the latest in Open Source PaaS but not necessarily a cutting edge Operating System. That's the background, but the reason I am bringing this up as a topic of discussion is mostly because I'd like to try and plan for the future as well as accommodate the present. At present, OpenShift Origin will run anywhere CentOS will run such as bare metal, VM on your laptop, VM in oVirt/VMWare, or a private cloud instance on CloudStack, Eucalyptus, OpenNebula, or OpenStack (listed alphabetically) or even public cloud provider instances like AWS, Google Compute Engine, or RackSpace OpenCloud (again, alphabetical). This is a feature we pride ourselves on but there are also plans to add plugins either into OpenShift or into IaaS platforms to add some fuctionality for auto scaling, load balancing, routing, etc. which brings me to the point which is where the lines between IaaS and PaaS start to blur. As many of you may know, during the last OpenStack summit, a group of companies announced the Solum project[1], which effectively provides a PaaS integration point into OpenStack. The OpenShift engineering team is participating in the Solum effort in an attempt to not duplicate work as well as to ensure have OpenShift is one of the PaaS providers on the forefront of this new OpenStack technology. Solum is still in the early phases, but it's certainly showing promise and from current impressions this appears to be a bridge between IaaS and PaaS. While this is only one example of some of the convergence that's possible, it's a real world example that I thought was worth bringing up for this discussion. This brings me back around to my original question, should we combine both PaaS and IaaS under the same umbrella SIG? Or does everyone think the two cloud service models differ enough to warrant separate SIG space? Or possibly another scenario I've not thought of? As an aside, I assume we could package them separately and allow users to enable CentOS repositories as they desire to install/setup/configure/deploy IaaS+PaaS and we could keep the logically separated that way but didn't want to make a rash assumption for the group and jump the gun with a CentOS PaaS SIG propsal. All that said, we're looking forward to offering up OpenShift Origin on the coming Cloud variants of CentOS distributions as well as supporting CentOS 6.5 as a deployment option for OpenShift Origin today[2][3]. Thoughts? Qustions? Comments? Thanks, -AdamM maxamillion on irc.freenode.net @TheMaxamillion on twiiter [0] - http://openshift.github.io/ [1] - https://wiki.openstack.org/wiki/Solum [2] - https://install.openshift.com/ [3] - http://openshift.github.io/documentation/#documentation

4 5

notifications of builds
by Karanbir Singh 15 Jan '14

15 Jan '14

hi its been a slight challenge coming up with an easy to consume format for build reports as we move to do mroe seven.c.o stuff, for the time being I am going to request Ralph to just get us another list and we can switch the build reports traffic over from the -qa list to this new list ( maybe build-reports as the name of the list ? ) A web ui would be nice, and mostly trivial, but I just want to get things out there doing as little work as possible ( so its done as soon as possible ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Presto drpms in vault.centos.org
by Johnny Hughes 14 Jan '14

14 Jan '14

All, We currently provide "presto - drpm" data in our current CentOS-6 tree and we all like that its there for speed of updates ... however, it is a couple hundred GB of space now in vault.centos.org for previous point releases. I would like to remove the drpms and rebuild metadata for the older centos repos to reclaim that space as we have 800GB of data there and if we don't cut back on size or get new machines for vault.centos.org to distribute, we are going to run out of space soon. I believe we can save between 100 and 150 GB by doing this now. It would also cut the size of repos moved to vault by 40-50 GB every point release. That means we can keep the current vault infrastructure for the foreseeable future with minimal impact on the mainline trees. Thanks, Johnny Hughes

4 5

updateinfo.xml data for CentOS repositories
by Shatil Rafiullah 14 Jan '14

14 Jan '14

Hi all, Could we revisit the missing updateinfo.xml in CentOS repos? A previous post (http://lists.centos.org/pipermail/centos-devel/2011-May/007480.html) mentioned it's difficult to get ahold of this data, but there have been developments since then. The Scientific Linux project publishes this data without issue, thanks to work done by OpenSUSE (http://lists.baseurl.org/pipermail/yum/2008-April/021802.html) and Oracle (https://blogs.oracle.com/linux/entry/updates_to_errata_on_uln) I'd love to get updateinfo.xml (or updateinfo.xml.gz) from CentOS rather than rely on another project, and I'm happy to contribute to making this happen. Shatil (@shatil)

5 7

CentOS Cloud SIG?
by Greg DeKoenigsberg 14 Jan '14

14 Jan '14

I remember once upon a time sending the first email to the Fedora Cloud SIG. Funny now to find myself sending an email asking about the CentOS Cloud SIG. :) Would love to find out what's required to get Eucalyptus packages into CentOS, and to build a Eucalyptus spin of CentOS. CentOS is already our platform of choice, all of our dependencies are either in CentOS or EPEL, and we've got an installer that sits as an updates.img on top of CentOS. Want to make sure we know the proper way of integrating into the new community. --g

10 17

Qt Creator for CentOS
by Dave Johansen 14 Jan '14

14 Jan '14

Is Qt Creator for Qt 4 available for CentOS (either 5 or 6)? I've installed the qt and qt-devel packages on CentOS 6 and I can launch Qt Designer, but is there a version of Qt Creator available? Thanks, Dave

1 1

oVirt and CentOS Cloud SIG
by Doron Fediuck 14 Jan '14

14 Jan '14

Hi guys, on behalf of the oVirt project, happy to join the community and we'll be happy to help where possible. Cloud SIG seems very relevant to oVirt. We're looking forward to assist with oVirt support as well. We have some CentOS fans in the oVirt community, so this should work well for everyone. - Currently we have our live oVirt [1] built using CentOS. So having you guys reviewing it would be beneficial. - For the standard el platform, we need some help with dependencies. Here's a short list which we would like to see go in over & above 6.5 * qemu-kvm compiled with RHEV flags * Support of librbd, libgfapi in qemu-kvm & libvirt, including sanlock & kernel modules * Network namespaces, VXLAN, GRE support in the IP stack (kernel through iproute, dnsmasq, etc) * The cloud-init version being used in RHEL 6.5. * Support of cgroups * selinux policies * Anything else you may be aware of. We'll probably find some more things on the way, but this would be a good start ;) Any suggestions from your side or things you'd like help with? Doron Fediuck [1] http://wiki.ovirt.org/OVirt_Live#oVirt-Live-1.1.iso_-_Oct_14th_2013

2 1

Documentation SIG
by Philip Mather 13 Jan '14

13 Jan '14

Has there been any interest or progress in the suggested Documentation SIG? -- Regards, Phil

4 3

A format request to create a Eucalyptus Special Interest Group
by Greg DeKoenigsberg 13 Jan '14

13 Jan '14

Hi folks. As I understand the "variants" proposal as it exists currently: http://www.centos.org/variants/ ...I think that the Eucalyptus installer, which relies upon CentOS currently, would do well as a variant. Which means that I would like to formally request the formation of a Eucalyptus SIG, according to protocol here: http://wiki.centos.org/SpecialInterestGroup So let me go through the requirements, one by one. * The topic for the group must be related to CentOS, or a use scenario for CentOS We build Eucalyptus, a cloud infrastructure application, around CentOS and have for 3 years now. We have an installer that is derived from Anaconda. We've sponsored CentOS events, and we deliver CentOS images to our users. Our packages are currently in a standalone repository, but we would be happy to merge these into whatever CentOS repository emerges (EPEL? Some new version of EPEL? CentOS core itself? I'm unclear on where this sits currently.) * There must be adequate control and feedback into the CentOS community Happy to discuss what this means to members of the CentOS community. * Generally, all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private; in such cases, please consult with the Devteam member out of band of the SIG Happy to do business on a centos-eucalyptus mailing list. * All code produced within the SIG must be compatible with a FOSS license presently used by CentOS; if a new license is wanted, again, please consult with the Devteam member All code is GPL or Apache. * All documentation produced within the SIG must be compatible with the license of this wiki Happy to do that. * We would expect teams to be watchful of general CentOS directions from the Devteam It would be a great advantage to have help from the Devteam to do this. * At least one member of the SIG, who need not be the lead, needs to be a member of the CentOS Devteam. We are not trying to enforce any moderation, however, we feel that the actions of each SIG using CentOS resources needs to have visibility to the Devteam Happy to work with anyone on the Devteam for this. How do we proceed? What discussion needs to take place, and who can say yes to move this request forward? --g

5 14

Unified Cloud SIG
by Rich Bowen 13 Jan '14

13 Jan '14

There seems to be some consensus in various different threads that what we need is a single consolidated Cloud SIG effort, and decide, over time, if it's sensible to split into project-specific SIGs. Easier to start consolidated than try to figure out how to merge later. For those of you not following all of the various threads, here's some high points: Dave Neary says: What I would like to see is a CentOS stack which allows all of the cloud storage, networking, virt management and IaaS projects to show themselves in a good light - we will need newer stuff that isn't available in RHEL 6 to do so (and the sam will doubtless happen during the RHEL 7 release cycle), and it makes sense for us to talk & share the burden of supporting those newer components on top of core CentOS. Karanbir says, in response to me: On 01/10/2014 02:36 PM, Rich Bowen wrote: > I'd love to see a "choose your own cloud adventure" LiveCD variant, > where one could easily compare, OpenStack, Eucalyptus, CloudStack, > OpenNebula, etc., either side-by-side, or as options during the startup. > That would be quite cool. Technically, if we can get nested virt going, the livecd need only be a bare min CentOS6 install, with VM's that run complete cloud instances inside it. That would also sort out the massive pain of network setup, since we could make some levels of predictions on what the state is on the host. In a few days time, we should have the live media churn process going, this might be an interesting PoC to start with. Sebastien Gosaquen says: My personal view is that it would seem strange to have one SIG per project, a single cloud SIG will require coordination efforts amongst project to agree on a somewhat common framework for build. We could probably start with a single cloud SIG to discuss and identify requirements/issues and then see if a split is necessary. Does this seem a reasonable approach to everyone as a way forward? -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

1 0

Cloud SIG interest from CloudStack
by Sebastien Goasguen 13 Jan '14

13 Jan '14

Hi, First, congrats to the centos community on the recent development. Reading the call for SIG, there is definitely interest from CloudStack to participate and create a ClouStack centOS variant for both instances and head/hypervisor nodes. Our default image template is already a centos template and our best quick start guide is based on CentOS. We also have a community run yum repo for all our packages. I see interest to create a Cloud Image for CloudStack clouds as well as creating variants for our management server and our hypervisor setup. I will be at the Dojo on January 31st and would be happy to discuss further. Cheers, -Sebastien Apache CloudStack PMC member

3 3

NethServer as CentOS Variant and SME SIG Proposal
by Alessio Fattorini 13 Jan '14

13 Jan '14

Hello everybody, my name is Alessio Fattorini and I'm part of a team of FLOSS developers that is working on a project named NethServer. We’d like to share with you our experience and our ideas for the future developments. You could think of NethServer as CentOS with some extra packages, particularly a powerful and extensible web interface that simplifies common administration tasks. NethServer is for the sysadmin who appreciates the effectiveness of a user interface which saves time compared to direct configuration file modification and for users who want to approach CentOS without having Linux skills. We didn't reinvent the wheel, NethServer is a partial rewrite of the original SME Server code, focusing on maintainability, extensibility and standard compliance with CentOS. We think we achieved those goals with: * A dynamic, streamlined user-interface * Standard components, tested widespread configurations * Minimal differences with upstream (CentOS) * Easy installation * Simplified administration tasks * Use of templates and text-based db for configuration (configuration will always be consistent) * Built-in extensibility NethServer architecture explicitly supports developers by making it easy to install and integrate additional software. We quickly added some pre-configured modules, installable with a “single click”, for example: LAMP framework Caching + filtering web proxy (with SSL filter) SOGo Groupware Mail Server with Antispam and Antivirus VPN (OpenVPN and IPsec/L2TP) Firewall (Shorewall) Intrusion detection (Snort) ownCloud More informations could be found on the official project website: www.nethserver.it. As soon as we read about CentOS variants, we have developed the idea of releasing NethServer as a CentOS variant and we are thinking of a SME SIG, a group exploring the needs of small enterprises (we are based in Italy, where the vast majority of enterprises is really small). According to you, does NethServer meet the basic requirements? We’ll be at Brussels Dojo and FOSDEM and we'd love to discuss directly with you our ideas. Cheers, Alessio and the NethServer team

10 16

the MRG setup
by Karanbir Singh 12 Jan '14

12 Jan '14

hi, the mrg stack has been in testing for quite some time, and there has been some work around the edges by users to test and make sure that its suiteable for what they are doing : by and large the response has been positive, even if private. I'd like to propose moving it to a more released state on x86_64. Thoughts ? Also, by definition this does not seem to be the sort of thing that the Core SIG should take up, but given that we have no other build route at the moment it might be something we need to handle there ( for the time being ). Anyone want to come help populate the MRG interest group a bit ? Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

[REQUEST] Create the CentOS Hosting SIG
by Jim Jagielski 11 Jan '14

11 Jan '14

One of the proposed Future SIGs (http://wiki.centos.org/SpecialInterestGroup) is the Hosting (or "Web Hosters") SIG. Since Web Hosters are one of the key and core users of CentOS, this seems like a SIG that should be started sooner, rather than later :) I'd like to propose that such a SIG be started. Following the proposed requirements listed: * The topic for the group must be related to CentOS, or a use scenario for CentOS. This is an obvious alignment. As noted above, CentOS is a popular choice for Web Hosters and ISPs. -- * There must be adequate control and feedback into the CentOS community Such feedback would be vital to the success of this SIG. -- * Generally, all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private; in such cases, please consult with the Devteam member out of band of the SIG. My preference would be to use public, archived lists for all development and communication. -- * All code produced within the SIG must be compatible with a FOSS license presently used by CentOS; if a new license is wanted, again, please consult with the Devteam member My preference that all new code and development be under the ALv2 license. -- * All documentation produced within the SIG must be compatible with the license of this wiki Agreed. -- * We would expect teams to be watchful of general CentOS directions from the Devteam My expectation would be an extremely tight feedback loop between the Hosting SIG and the general CentOS direction. -- * At least one member of the SIG, who need not be the lead, needs to be a member of the CentOS Devteam. Agreed. I welcome suggestions. A bit about myself: Web Hosting is near and dear to my heart, having created a small ISP/Web Hosting business and helping develop the Apache HTTP server. I've been known to speak and write about web hosting. I am currently employed by Red Hat, Inc. but this request is not being made formally with my Red Hat hat on.

11 15

Repositories in new ecosystem and Desktop version
by Ljubomir Ljubojevic 10 Jan '14

10 Jan '14

Hi. Repository policy will define how new ecosystem works, so I thought throwing in few suggestions and see what can be applied. Will one of CentOS variants/SiGs also include something like Desktop/Laptop/Workstation variant that will provide out-of-the-box EPEL and ElRepo packages, mostly drivers? I see lack of (network) drivers on installaion DVD as a main problem for newbies that chose CentOS as their workstation. Something in line with CentOS + ElRepo drivers on the same DVD + current release/.repo packages for EPEL, and maybe other 3rd party repositories. I am trying to image how this would be best to execute, and the first thing that comes to mind is this: 1. yum-plugin-priorities should become mandatory for all CentOS Variants including Base distro. 2. All .repo files should have "Enabled=" and "Priority=" lines for every repository, so it is easier for a user (or SiGs) to set things up as he likes it. 3. There should be debate and consensus (with 3rd party repositories!) how to decide which priority numbers will be assigned to which repository (including base/os and others from current CentOS project) so that that repository system in EL ecosystem is much easier for re-purposing of the already installed systems. Priority for CentOS-Core should be enough to insert 2 repositories above it, and system should use rounded numbers (10,20,30,40 or better 20, 40, 60, 80) for repositories, so there is room to insert additional repositories when/if they appear. The way I see it, there can be two paths to building Variants. * First is to create separate (mostly symlinked) repositories for each Variant. * Second is to use priorities wisely so that packages that need to replace ones from CentOS-Core are placed to a repository that has higher priority (lower number) in "Priority=" line. So if you want to convert CentOS-Core system to CentOS-Desk you only need to ADD centos-desk-release package and update the system. I think second path is much better for 3rd party repositories that will provide things that are not opensource like non-opensource codecs (gstreamer, vlc, ...) without a need for complicated editig of .repo files. Biggest benefit from this will be for newbies that are currently frustrated with lengthy process and rather chose Debian based systems like Ubuntu and Mint for their first Linux distros. Consequence is once they learn Debian way they are not really interested to additionally learn CentOS/RHEL way to run CentOS servers. As a person that is some 5 years in newbie support of CentOS/RHEL (currently main admin on official CentOS Facebook group with 6.000 members), main problem to attracting newbies/future admins is complicated addition of Desktop packages via 3rd party repositories. Sometimes I even give up on explaining total newbie how to add all those extra repositories. 4. Tool for easier management of various repositories should be developed/adjusted existing? so that newbie from GUI (or CLI) can move individual repositories up/down and turn them on/off to adjust them as they see fit, then save various options as profiles (some made by CentOS Project?) and easily switch them (or temporary apply them for current terminal?) to accomplish various tasks. Yum devs could probably help with this. 5. There should be additional "Downloaded" repository that would carry latest packages that do not have their own yum reposiroties like VirtualBox, LibreOffice, Skype, shorewall, flash, etc. I believe an arrangement with providers of those binaries could be achieved for themselves to upload latest versions so users are able to installed them without need to download and apply them manually. Same method could maybe be used to carry a subset of some other repositories, provided as-is, like latest Firefox/Thunderbird from Remi repository for those that do not care about compliance to standards of government datacenters (or whatever it is called). A mechanism for approval of those packages can be carefully designed, but I think they are also an important part of Desktop userbase. At the moment, "downloaded" section in my repository caries about 200 packages manually downloaded (or copied from) from other places, like codecs with accompanying requirements etc. Even tho I do not update them very often, I have them on-hand when I install new system, just a yum command away. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant

2 4

Interest in a 32bit tree of the upcoming CentOS7?
by Andreas Thienemann 10 Jan '14

10 Jan '14

Hi, I'm in the process of building myself a 32bit tree of the RHEL7 beta as I do have a few x86 machines I am not ready to retire yet. Now that CentOS is all open and community etc. I was wondering if there'd be some interest for me to rebuild the results within the CentOS project and turn it into an official release long term. My unfinished work so far is based on an older RHEL5 buildsystem I still had lying around but I am happy to switch this to the CentOS toolstack if there's interest. This would mean filing off the serials, removing trademarks and all these things which I hadn't planned on doing initially but on the other hand, it should be very easy doing that benefitting from the regular CentOS work on these topics. Is anyone else interested in a i[36]86 build of CentOS7 and would be willing and able to contribute to it? Or is x86_64 the only release really needed? If there's some interest, I am sure this could be turned into a nice project. cheers, Andreas

9 9

Build Extra Minimal Instalation Centos 6.5
by Marcos Carraro 10 Jan '14

10 Jan '14

Helo, I need more information, for create a extra minimal instalation on my Centos 6.5, I would like to know what are the packages that I could uninstall to lighten the Centos also like to know how can I do to lower the consumption of the same ram. Sorry my English.... *--* Att Marcos Carraro about.me/marcoscarraro

3 5

Cloud-Infra SIG creation request
by Mike Burns 10 Jan '14

10 Jan '14

We're looking to create an easy to use distribution of RDO/OpenStack built on CentOS. Our understanding is that we need to first create a SIG and then we're able to create 1 or more variants. What we'd like to do: * Provide all the dependencies that are either not in base CentOS or are too old in the base CentOS in a single location (maybe a distinct yum repo) * Be able to build and sign packages needed to run RDO/OpenStack within the CentOS infrastructure * Be able to generate a LiveCD in the CentOS infrastructure that allows people to get up and running quickly. * Provide Install media for people that do not want to use a LiveCD. It may make sense to create the Cloud Infra sig for this and use that going forward. Any suggestions or questions so we can move forward on this? Thanks Mike Burns on behalf of The RDO Team

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel January 2014