devel

devel@lists.centos.org

11 participants
4618 discussions

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

Any plans to rebuild RHS under CentOS?
by C. L. Martinez 10 Jan '14

10 Jan '14

Hi all, Exists some plans to do a rebuild of RedHat Storage Server in CentOS distribution?? Thanks.

3 5

Policy Proposal for bugs.centos.org
by Christoph Galuschka 10 Jan '14

10 Jan '14

I don't know if there have been any thoughts around on this, but I think there is no form of policy in place regarding the CentOS bug-tracker? I'm thinking along stuff like i.e. no activity for > 1 year --> close issue. I would like to hear feedback (suggestions if there are some) on this thought. If we want to move something like that into place (and there is enough feedback), i'd be willing to write an initial draft to expand upon. Thanks and Cheers Christoph -- Christoph Galuschka CentOS-QA member | IRC: tigalch --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com

6 11

CentOS-6.4 OpenStack testing cloud images
by Karanbir Singh 08 Jan '14

08 Jan '14

Hi, CentOS-6.4 i386 and x86_64 images targetting OpenStack are now available for testing at http://dev.centos.org/centos/hvm/ Images are available for KVM, Hyper-V, VMware, Xen and any other HVM hypervisor. Although, the 6.x kernel has the pv support enabled, so should work fine under paravirt Xen as well. Images are published as raw, qcow2 qcow2compressed and vpc ( vhd ) for both i386 and x86_64 CentOS-6.4 The images represent media versions, and have not had an update run against them. Its highly recommended that in testing, please check this version *then* do a yum update and repeat tests to ensure that there is no test result change in the 6.4+updates tree's. Keeping in line with the general CentOS Cloud strategy, ie to help people migrate or investigate cloud instances, we expect the images to represent as close as possible to a real machine CentOS install ( ie. no cloud specific user, people use root to login, selinux is enabled ). With some exceptions like isdn support is removed, as is cups and bluetooth since those things make little sense on a cloud instance ( nothing stopping the users from installing them later if they need to ). Also, cloud-init is included. This is based on the 0.7.x stream and based off sources published by Red Hat in their RHEL-Common/ tree. md5sums: ac6c1f683f18ec2742fc620930b6b77a CentOS-6.4-i386-Minimal-OpenStack.image.bz2 ac6c1f683f18ec2742fc620930b6b77a CentOS-6.4-i386-Minimal-OpenStack.image.qcow2.bz2 d0ef1077886714d9808eb21b0d35b64e CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2 853487ac600963da6c00f69be10f11d5 CentOS-6.4-i386-Minimal-OpenStack.image.raw.bz2 dc16f7339c97856514ce35f65196a928 CentOS-6.4-i386-Minimal-OpenStack.image.vpc.bz2 9169abb16ad2b0a0195574fc8c7c6e7a CentOS-6.4-i386-Minimal-VMware.image.vmdk.bz2 1c1ff6ffca8ca7845f49a017f5386961 CentOS-6.4-x86_64-Minimal-OpenStack.image.bz2 1c1ff6ffca8ca7845f49a017f5386961 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2 2d9a25fa573b3c512e97c9d6cea64657 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2c.bz2 f701914d4eafb563b086853cd8e7e79d CentOS-6.4-x86_64-Minimal-OpenStack.image.raw.bz2 8476063151f9163ba37e260e144270e1 CentOS-6.4-x86_64-Minimal-OpenStack.image.vpc.bz2 a68f0bd1328bd67056e07be8501607a0 CentOS-6.4-x86_64-Minimal-VMware.image.vmdk.bz2 sha256sums: 2418f233fabc02074e54f705667ba16e2845883863e5c2e860ffc5b615f1a096 CentOS-6.4-i386-Minimal-OpenStack.image.bz2 2418f233fabc02074e54f705667ba16e2845883863e5c2e860ffc5b615f1a096 CentOS-6.4-i386-Minimal-OpenStack.image.qcow2.bz2 1156a84f18c62e5bb04d82976e6c7aa412c8486de0780e35b42f97697fe06aed CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2 70c9c4f1a44b8ef349ca13da1993c1b9211a1ec72f68b4ddfc85ad21e70e6e97 CentOS-6.4-i386-Minimal-OpenStack.image.raw.bz2 ec1e5ab7508d9139df110e4a5c957c56a4dc6011fc8030cb6e48d3f6a27866ab CentOS-6.4-i386-Minimal-OpenStack.image.vpc.bz2 675c9717b82b71833cb074e76357aa2325d03730d989507110caa0e6d2e4cb5c CentOS-6.4-i386-Minimal-VMware.image.vmdk.bz2 a68e76596568b9e3117f021ba4d1db983b763ef31097b9aa47139927dcbf14bc CentOS-6.4-x86_64-Minimal-OpenStack.image.bz2 a68e76596568b9e3117f021ba4d1db983b763ef31097b9aa47139927dcbf14bc CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2 888da1ac03dd78027421db0629d899187456058a72a6e555d459bcb1d4f20296 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2c.bz2 4626a83e8d0c706d9303874d0e26d2b127983207adb7a64e079e359e6b33a156 CentOS-6.4-x86_64-Minimal-OpenStack.image.raw.bz2 3bd4c91b276e9b4a049fd5ecd32e6e538593331a1298162ffe07e9033eefd903 CentOS-6.4-x86_64-Minimal-OpenStack.image.vpc.bz2 8c70a927d761e99e1529585b43d8dc2e080977b00436ec7038288d542fba6d4c CentOS-6.4-x86_64-Minimal-VMware.image.vmdk.bz2 Note: these images have not been through a regular CentOS QA cycle, and I am requesting people to actually test these in either dev or test environments that run the hypervisor being tested, the cloud controller being tested and provide feedback here to the mailing list. Please clearly indicate what hypervisor was used, what cloud controller and versions of the relevant software. As a baseline the CentOS CI tests ( https://gitorious.org/testautomation/t_functional ) is a good place to start, if you just need tests to run ( although these tests mostly target machine instances, its still a good baseline for these images ). And while you are at it, please feel free to submit cloud, virtualised, instance and image specific tests. The overall aim is to be ready for inclusion of Cloud image release in sync with iso and distro release for next-version ( 6.5 most likely ). Apart from baseline testing, I am also looking for feedback on package manifests included in the images ( should we add something ? should we remove something ? ) and if there is any need / scope for publishing specific role images as well ? ( eg. should we do a LAMP image ? ) Finally, I want to thank Alessandro and Octavian from Cloudbase Solutions for helping get this effort off the ground, and then their patience as I went through the mechanics of automating the build process and getting the images ready. Enjoy! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

5 13

drpms directories taking a lot of space
by Florian La Roche 08 Jan '14

08 Jan '14

Hello, some weeks ago I looked briefly at the drpms subdirectories for Centos-6.4-x86_64. All updtes took about 4GB whereas the drpms subdir had already 27GB. Listing the drpms directory by size showed e.g. libreoffice updates taking e.g. 35MB whereas the full update rpm is 37MB. Is it possible to move the drpms directories to special mirrors only. Similar to the debuginfo/source/oldreleases? Maybe also some tuning is possible to generate drpms only if they really give a huge download saving. Sorry, I don't have detailed numbers anymore, I've just disabled to mirror the drpms subdir for now. (All numbers above are from memory, my local mirror doesn't have drpms anymore.) Keeping the official CentOS mirror rather small should be a real plus for the large volume of mirror sites and the real good distribution of CentOS. Thanks a lot for CentOS, Florian La Roche

3 6

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