devel December 2010

devel@lists.centos.org

54 participants
26 discussions

11IEA-AIE-SS-ROS
by Savaş TAKAN 03 Dec '10

03 Dec '10

Dear potential author, we are organising a special session on robot operating systems: http://dive.iyte.edu.tr/11IEA-AIE-SS-ROS/RobotOS.html Please consider submitting a paper. Sincerely, Bora -- Savaş TAKAN

1 0

Reality V/s Fantasy
by Karanbir Singh 03 Dec '10

03 Dec '10

Hi Florian, On 11/26/2010 10:41 AM, Florian La Roche wrote: > you should make sure to grow the CentOS development to a > bigger group and make it more stable. AKAIK this is the > goal of this list and there should be plenty of work to > distribute and get done. I am not sure where that came from - there is some level of fantasy that some of you guys seem to live with. Lets take for example the request for help with branding and trademark searches in the el6 source base. Then look at the people who really did anything to help, take the usual suspects out of the loop, and then see what the number reduces to.. Consider this : the distro was ready to QA in 72 hrs from when upstream dropped all srpms into the right places. I actually requested the 'usual suspects'[1] to not get involved with the branding issues, we all have quite a bit going on and adding onto that at release time usually means slowing down or dropping other efforts; the intention was to not do that, and to bring in a larger user base who can help cover issues that don't need specific centos resources. Also, the QA effort tends to be exceptionally manic, with things changing on an hourly basis, and some of us pushing for testing, results quite aggressively. Besides that, new release, new buildsys, new repo structure and new process meant that this would be fantastic time for a larger number of people to get involved, and stay involved. Starting from the root of what we do, and having a good understanding of context around it, why its a big deal and appreciate it in specific terms by working on it. The original email asking for help on this was posted on the 12th Nov. Its the 26th now. Check https://bugs.centos.org/ to see what level of participation has been forthcoming. Lots of people will argue that open source works in a way where people do what they want to do, so you cant tell them what needs doing - and they will do what they want, when they want. Its what many imagine is the 'fun' in the open source way. Fortunately, or unfortunately we dont have that luxury. What comes down the pipe needs to be addressed, sometimes its what we want to do - and sometimes its what needs doing because that's the issue on hand. The process we have in place is mostly finite, with a specified origin and a specified delivery expectation. We need to join those dots. And if people don't want to help with that joining-the-dots effort, they are never going to be a part of the process. So when people imply that there are lots of potential-contributers who would want to get involved and help etc : What fantasy world are they looking at ? I, or one, would like to get in on that action please. > No fights please, CentOS has such a wonderful source > base to extend upon... If we cant get traction to get on with just doing what our primary aim is, extending the code base looks to be a bit of another fantasy world. Slightly frustrating ? Absolutely. - KB [1]: The usual suspects being the people already doing quite a bit, the core/dev team, the qa guys, artwork effort. And I am truly grateful for their support.

12 21

Fasttrack for C-5
by Alan Bartlett 03 Dec '10

03 Dec '10

Karanbir, Is there an ETA for this repository yet? A status update would be appreciated, please. Regards, Alan.

10 33

handling ABRT
by Karanbir Singh 03 Dec '10

03 Dec '10

hi, EL6 now includes abrt ( https://fedorahosted.org/abrt/ ), which is setup to talk with bugzilla.r.c and comes with a plugin that allows details passed to rhsupport. We dont really want either of those two things to happen. So we can either : - Remove abrt completely ( might not be the best overall solution, but it would surely be the fastest short term target ) - Leave abrt in the distro, but disable chatter abilities with anything *.r.c; and *.fedoraproject.org ( that leaves functionality partially intact, but local implementations would need to adopt and go with whatever they want / need; this solution might not be as nice as the last option) - Last option: get a plugin together that can do what's needed to file at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! ) Who wants to take on the task of handling abrt, getting the work done and driving this issue into CentOS-6 ? Being able to code in python might not be optional.. - KB

14 39

build errors with RHEL6 packages
by Hubert Bahr 03 Dec '10

03 Dec '10

On 11/13/2010 02:17 PM, Karanbir Singh wrote: > On 11/13/2010 08:25 AM, Farkas Levente wrote: >>/ - what os, version do you use on build hosts? /> > CentOS-5.5 >>/ - which version of mock and ccache do you use? / > no ccache, mock-0.6.3 >/ - and what mock config do you use? / > nothing interesting in the mock configs. If there is nothing interesting in the mock configs why not share them. The config really defines the build environment not the host and not necessarily the version of mock. It is the default installs + the packages to meet dependancies and where they come from. >>/ since it's well known that there are some packages (like bash, nss) / ? because you have those problems, does not mean everyone else will. >>/ which can not be build in mock on rhel-6: />>/ https://bugzilla.redhat.com/show_bug.cgi?id=613392 />>/ https://bugzilla.redhat.com/show_bug.cgi?id=609201 />>/ so it's rather strange that build complete without issues. / > Speak to the people who have the problems ? These packages have all > clearly built not only for fedora, but also for red hat - and going by > the changelogs, quite a few times. > - KB Since I have built all but 36 packages on both 1686 and x86_64 with rpmbuild I am very interested in resolving the differences in build environments. Once I too have a stable build environment I would be interested in working on the rebranding etc. But I would like to be able to test and make sure my changes are not causing the problems not the Build environment. I am building on RHEL6 + updates. Hubert

3 5

Considering repo re-structuring
by Karanbir Singh 02 Dec '10

02 Dec '10

Hi Guys, Some micro-conversations have taken place around this issue on various venues and its worth bringing all that together into one place. With EL6, the rpmlist has grown quite a bit, also there are components that Red Hat ship out in their 'optional' repo. Which are not available on the main isos. Or so I've been told - if you can verify that, please do. The other thing to keep in mind is that we have always merged in all packages from various variants that upstream ship - making all packages available to everyone was always the aim. So traditionally, CentOS has maintained the distro repositories in 2 url's: [os] [updates] with [os] reflecting whats on the isos/; as close to exactly as possible. With CentOS-6, we might need to reconsider that - there is way too much content to fit onto a single DVD. And having the main distro on multiple DVD's might be an option, but is that the best option ? to expand on that option, we could merge in all packages, built a DVD iso set ( 2 or 3 disks, whatever is needed ), stick with the [os] and [updates] repo's on mirror.c.o - and then potentially consider doing some 'slimmer' options. eg: CentOS-6-Minimal, or CentOS-6-SMB-Server etc. The other option is to split the repos into [os] [updates] [optional] {1} [optional-updates] {2} {1} or use a better / different name {2} do we even need the second -updates, we could go with what the present policy w.r.t centosplus/extras is - and drop updates into the same repo Then stick with what we have done in the past, use the isos to reflect whats in [os], create the ability for people to use the [optional] repo at install time and go with that. The iso content would be dictated by the merged iso contents from upstream, so we retain the CentOS <= 5 process in that regard. Continuing on the same idea, one thing that came up was reporpose the Extras/ repo and use that to host these 'additional/optional' packages. Given that it changes a massive user expectation - unless there is very good reasoning to do this, lets try and avoid this. - KB

19 58

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel December 2010