devel

devel@lists.centos.org

18 participants
4604 discussions

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

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