devel December 2014

devel@lists.centos.org

38 participants
42 discussions

cockpit-ws should require GLib 2.37.4 or later
by Stef Walter 12 Dec '14

12 Dec '14

Packagers of Cockpit might be interested in this pull request. We'll start to describe our dependency on GLib more accurately. Since versions of GLib before 2.37.4 crash with cockpit-ws, we'll refuse to build on those versions. https://github.com/cockpit-project/cockpit/pull/1586 This is the bug in question: https://bugzilla.gnome.org/show_bug.cgi?id=701283 https://bugzilla.redhat.com/show_bug.cgi?id=1143943 However if your distro has patched GLib to fix this bug (I think CentOS has done this), you can use the mechanism provided by pkg-config to override the check in question. This is described in the failure output of configure when this dependency are not met: > Alternatively, you may set the environment variables GLIB_TLS_CFLAGS > and GLIB_TLS_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. Cheers, Stef

1 0

SCST would like to join the CentOS Storage SIG
by Vladislav Bolkhovitin 12 Dec '14

12 Dec '14

Resending, because it turned out that this is subscribers-only list and I was subscribed from another address, dedicated for mailing lists. ==================================================================================== Hi CentOS Developers, I would like to ask if SCST project can join the CentOS Storage SIG? We would like to have a CentOS kernel with SCST included be part of CentOS to let our users easier access to the latest SCST versions on the latest kernels. If you don't object, what should we do for that? Kernel requirements are simple. It's just a standard kernel plus one patch applied + SCST modules. We already have a script, which creates a kernel RPM with SCST integrated for the specified kernel. SCST is an alternative SCSI target stack for Linux. SCST allows creation of sophisticated storage devices, which provide advanced functionality, like replication, thin provisioning, deduplication, high availability, automatic backup, etc. Majority of recently developed SAN appliances, especially higher end ones, are SCST based. It might well be that your favorite storage appliance running SCST in the firmware. For instance, from 12 storage systems mentioned in http://www.theregister.co.uk/2013/10/30/emc_to_ejaculate_xtremio_at_launchg… (counting the system this page is about as well), 6 are SCST based. More info about SCST and its modules you can find on: http://scst.sourceforge.net Thanks, Vlad

2 3

A project calendar
by Karanbir Singh 11 Dec '14

11 Dec '14

Hi There is quite a lot of stuff going on and not all of it is easily visible to everyone. The way to perhaps address that is to setup a project calendar that people can sync against and look at regularly. And more win if we can have it slightly open ended, allowing people / projects / sig's to contribute events into that cal. To that extent Stephen Smoogen introduced me to Pierre-Yves Chibo who runs the fedocal effort, and they have graciously agreed to set something up for CentOS as well. Stephen I know is on this list already, I've requested Pierre to join ( he might have done so already ). Firstly looking for comments on the idea / plan - and then for options on implemention, publishing and consumption of the calendar. Regards -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc

8 11

Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-10)
by Honza Horak 11 Dec '14

11 Dec '14

Mainly discussed git repositories: * hhorak will send initial list of packages to Evolution to start with git structure preparation * we'll include mongodb26, mariadb100, postgresql94, php56 and httpd24 collections for beginning and continue with other larger collections later * it seems we do not need to provide all collections as upstream collections unless there are any changes from downstream collections * building downstream collections (currently only source rpms are automatically sync from RH) will be figured out after we can build upstream collections * we'll have 2 repos, 1 for "devel" (upstream) and 1 for "stable (downstream, those currently synced) * build in cbs setup was not tested yet * buildroots for collections will include all built packages, but need to be separate for collections to be able to install different sclname-build packages inside the buildroot * nothing like bodhi is in centos right now; script automatically pull all builds tagged somehow (every 10 minuts) * when extending the SIG with other SCL maintainers, info about them will be placed on the wiki page * project admin code conflicts with the commit by branch acl thing we have... kbsingh will work it out * hhorak will send an invitation for the meeting the next week, the meeting will be at the same time, same place Full meeting log attached. Conversation may continue at https://www.redhat.com/mailman/listinfo/sclorg. Honza

2 1

Community test infrastructure
by Karanbir Singh 10 Dec '14

10 Dec '14

Hi, The CentOS project has some reasonable test infra in place that tests for the content inside and the installer / media for CentOS Linux. The big two parts of this currently are : 1) Functional tests for the platform are visible at http://ci.dev.centos.org/ and are always being expanded. More information about the setup this runs on is available at : http://wiki.centos.org/QaWiki/CiDev and details on the t_functonal test suite ( what we consider our acceptance tests ) are at: http://wiki.centos.org/QaWiki/AutomatedTests/WritingTests/t_functional 2) The platform tests : where we test the distro as a whole, including the installer and delivery media, are run on an old IBM BladeCenter. More info at : http://wiki.centos.org/QaWiki/Hardware Over the last few weeks, I've been looking into setting up and running a wider community available and driveable test infrastructure that allows projects outside of CentOS Linux to come and test their code via a CI or a CD process against CentOS Linux. The aim being to allow them to constantly integrate within their own environment but also to test against CentOS Linux constantly. Allowing both sides of the equation the ability to deliver confidence and to spot issues arising from changes as early as possible. As the collection of projects in this mix grows, it would allow them to not only CI against CentOS Linux, but also amongst each other, thereby setting up a level of trust-matrix across evolving code. Towards this goal, we have some hardware that has come online and we've spent ( its mostly only been Fabian! ) some time playing with the platform and getting used to the setup. The platform is a large SeaMicro integrated chassis that includes 64 physical nodes, that can be controlled via an api to the management unit. Details for the hardware setup are available at : http://wiki.centos.org/QaWiki/PubHardware Just as a differentiator, we are calling this setup ci.centos.org, where external projects can come test and integrate against CentOS Linux. As opposed to ci.dev.centos.org where we test CentOS Linux itself. The overall aim being that we deliver into ci.centos.org a known good CentOS Linux platform that has already been through a level of trust-buildup. Then being delivered on a platform we trust, we hope that failure reports down to infra or CentOS Linux itself are minimised - creating a higher level of trust in the test-run output for the external projects. In order to deliver services, the workflow that I've been thinking about is to request folks to ask for access to this infra via bugs.centos.org and provide details on what they want to test and how. Based on that we can allocate either physical or virtual machines in the machine pool, and setup the jenkins jobs + create acls etc allowing the project to get access to manage their jobs. They would then be able to setup the callback triggers from either git.centos.org or from external git repositories and also from CentOS rpms. The service delivery is run from a couple of servers hosted outside the SeaMicro unit. This is where we would run the jenkins instances, the local mirrors, jump hosts and admin nodes to manage the seamicro instances - allowing for the entire seamicro unit to be available for testing purposes only. diagrams on http://wiki.centos.org/QaWiki/PubHardware should help clear out the exact setup and how this runs. The layout and process being proposed is based around conversations we've had with a few other projects on what might work best for them in order to come and test with us, however the process and workflow and even components we use in the setup are very much up for conversation and change. One issue recently highlighted was that some projects might not want to use jenkins, and thats ok - we are willing to setup and run something else as needed as well. >From the CentOS Project side of things what we want to focus on is running the hardware, helping admin the service delivery machines and help projects onramp into this environment - we need the projects to come forward and actually run the tests, consume the results and take actions as needed from fallouts. And this can be either projects associated with CentOS in the SIGs or completely orthogonal third party projects looking to get involved in the larger CentOS ecosystem. We welcome projects that need physical machines to run their tests on, and even those that need clusters of machines. For the actual test runs, we wont really have persistence in test environments. We will be automating the provisioning and deployment, so that the machines can be reinstalled after the test run is done and reused for other purposes. And we encourage folks to test on baremetal since that means tests should complete faster, and unless it really is a virtualisation technology being tested, you are more likely to be closer in terms of user-facing-test-cases. I am now soliciting comments, questions and interest from external projects who might be willing to come work with us here. We are in a ready-to-go state here. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 1

Fwd: SCST would like to join the CentOS Storage SIG
by Karanbir Singh 10 Dec '14

10 Dec '14

forwarding for Vlad, he wasent subscribed to the list at the time : -------- Forwarded Message -------- Subject: SCST would like to join the CentOS Storage SIG Date: Fri, 05 Dec 2014 21:43:41 -0800 Hi CentOS Developers, I would like to ask if SCST project can join the CentOS Storage SIG? We would like to have a CentOS kernel with SCST included be part of CentOS to let our users easier access to the latest SCST versions on the latest kernels. If you don't object, what should we do for that? Kernel requirements are simple. It's just a standard kernel plus one patch applied + SCST modules. We already have a script, which creates a kernel RPM with SCST integrated for the specified kernel. SCST is an alternative SCSI target stack for Linux. SCST allows creation of sophisticated storage devices, which provide advanced functionality, like replication, thin provisioning, deduplication, high availability, automatic backup, etc. Majority of recently developed SAN appliances, especially higher end ones, are SCST based. It might well be that your favorite storage appliance running SCST in the firmware. For instance, from 12 storage systems mentioned in http://www.theregister.co.uk/2013/10/30/emc_to_ejaculate_xtremio_at_launchg… (counting the system this page is about as well), 6 are SCST based. More info about SCST and its modules you can find on: http://scst.sourceforge.net Thanks, Vlad

1 0

building (and opening) the CentOS web presence.
by Jim Perrin 08 Dec '14

08 Dec '14

Over the next few days I'll be working to clean up a few odds and ends for various CentOS websites, include bugs, w.c.o, and seven. What I'd like to do is open the development and engineering of the website so that others can help and/or contribute as well. To help with this, I'll be migrating a few things on/around git.centos.org so that they can be made public. If you're interested in helping with this effort, and have a background in web design and and/or ruby, please let me know. Current tools in use: - nanoc http://nanoc.ws/ - bootstrap - haml - jquery Proposed tools for future development: - middleman http://middlemanapp.com/ -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

1 0

CentOS Atomic SIG reminder: Tuesday 14:30 UTC
by Joe Brockmeier 08 Dec '14

08 Dec '14

Hi all, Reminder, we have the usual CentOS Atomic SIG meeting tomorrow at 14:30 UTC in #centos-devel. Stef Walter is going to be joining this week to discuss Cockpit, since we had some open questions around Cockpit a while back. We should also discuss nightly tree builds and eventually having a "stable" and "testing" tree or how that will work, and what options we have and are working towards there. Finally, I'd like to discuss inclusion of Rocket and whether any packaging work is going on there already. Also: From last week: #action lsm5 to begin building rawhide kube packages in virt7-testing #action imcleod to test compose using the latest CBS content to verify proper kube setup #action lsm5 to refresh cockpit packages in CBS Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

1 0

No CBS/Infra Meeting this week (Next Meeting: 15-Dec-2014)
by Brian Stinson 08 Dec '14

08 Dec '14

Hi All, Just a reminder that we are switching to have the CBS/Infra meetings every other week. This Monday is our week off. If there are agenda items that should be discussed at the 15-Dec meeting please let me know. Thanks! Brian -- Brian Stinson bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk

1 0

CentOS 6 build logs
by John Newbigin 05 Dec '14

05 Dec '14

Hi, I am sure this must have been asked before but I have been unable to find it anywhere... I am looking for the build parameters & logs for EL6, specifically for the libvirt package. The reason behind this is that I an trying to rebuild libvirt with a patch but my rebuilt version does not run. There is a stack of --with and --without options which I might need to provide. In the first instance, I just want to replicate the c6 build for this package. Thanks, John.

2 1

Dependency problems in C5 Extras with gmime, drbd, xfprint, EPEL
by Anssi Johansson 03 Dec '14

03 Dec '14

I found these dependency problems when running repoclosure with the -n option, which makes repoclosure consider only the newest versions of each package. #1 and #3 are only a problem if EPEL is enabled. I'm not sure if these require any action, but I wanted to get these off my chest anyway. Issue #1, gmime: The following packages are in CentOS 5 Extras: - gmime-2.2.10-5.el5.centos - gmime-devel-2.2.10-5.el5.centos - gmime-sharp-2.2.10-5.el5.centos EPEL has: - gmime-2.2.26-1.el5 - gmime-devel-2.2.26-1.el5 Now if someone has gmime-sharp-2.2.10-5.el5.centos and its dependency gmime-2.2.10-5.el5.centos installed and runs "yum update" with EPEL enabled, there will be a dependency problem. yum would like to update gmime to 2.2.26, but it can't, because the old version is required for gmime-sharp. Issue #2, drbd: The following packages are in CentOS 5 Extras: - drbd-8.0.16-5.el5.centos - drbd82-8.2.6-1.el5.centos - drbd83-8.3.15-2.el5.centos - kmod-drbd-8.0.16-5.el5_3 - kmod-drbd-xen-8.0.16-5.el5_3 - kmod-drbd82-8.2.6-2 - kmod-drbd82-xen-8.2.6-2 - kmod-drbd83-8.3.15-3.el5.centos - kmod-drbd83-xen-8.3.15-3.el5.centos If I install kmod-drbd and its dependency drbd with "yum install kmod-drbd" and then run "yum update drbd", yum will attempt to replace drbd with drbd82, because drbd82 obsoletes drbd. This will fail, because drbd is required by kmod-drbd. Issue #3, xfprint: xfprint-4.4.2-1.el5.centos is in CentOS 5 Extras. If I have installed that with "yum install xfprint --disablerepo=epel" and then run "yum update" with EPEL enabled, I get this: --> Running transaction check --> Processing Dependency: libxfce4mcs-client.so.3()(64bit) for package: xfprint --> Processing Dependency: libxfce4mcs-manager.so.3()(64bit) for package: xfprint ---> Package libxfce4util.x86_64 0:4.6.2-1.el5 set to be updated ---> Package libxfcegui4.x86_64 0:4.6.4-1.el5 set to be updated --> Processing Dependency: xfce-mcs-manager >= 4.4.2 for package: xfprint ---> Package xfce4-settings.x86_64 0:4.6.5-3.el5 set to be updated --> Processing Dependency: libexo-0.3.so.0()(64bit) for package: xfce4-settings ---> Package xfconf.x86_64 0:4.6.2-3.el5 set to be updated --> Running transaction check ---> Package exo.x86_64 0:0.3.107-2.el5 set to be updated --> Processing Dependency: xfce4-doc for package: exo --> Processing Dependency: libxfce4mcs-client.so.3()(64bit) for package: xfprint --> Processing Dependency: libxfce4mcs-manager.so.3()(64bit) for package: xfprint --> Processing Dependency: xfce-mcs-manager >= 4.4.2 for package: xfprint --> Running transaction check --> Processing Dependency: libxfce4mcs-client.so.3()(64bit) for package: xfprint --> Processing Dependency: libxfce4mcs-manager.so.3()(64bit) for package: xfprint --> Processing Dependency: xfce-mcs-manager >= 4.4.2 for package: xfprint ---> Package xfce4-doc.x86_64 0:4.6.2-3.el5 set to be updated --> Finished Dependency Resolution xfprint-4.4.2-1.el5.centos.x86_64 from installed has depsolving problems --> Missing Dependency: libxfce4mcs-client.so.3()(64bit) is needed by package xfprint-4.4.2-1.el5.centos.x86_64 (installed) xfprint-4.4.2-1.el5.centos.x86_64 from installed has depsolving problems --> Missing Dependency: xfce-mcs-manager >= 4.4.2 is needed by package xfprint-4.4.2-1.el5.centos.x86_64 (installed) xfprint-4.4.2-1.el5.centos.x86_64 from installed has depsolving problems --> Missing Dependency: libxfce4mcs-manager.so.3()(64bit) is needed by package xfprint-4.4.2-1.el5.centos.x86_64 (installed) Error: Missing Dependency: libxfce4mcs-client.so.3()(64bit) is needed by package xfprint-4.4.2-1.el5.centos.x86_64 (installed) Error: Missing Dependency: xfce-mcs-manager >= 4.4.2 is needed by package xfprint-4.4.2-1.el5.centos.x86_64 (installed) Error: Missing Dependency: libxfce4mcs-manager.so.3()(64bit) is needed by package xfprint-4.4.2-1.el5.centos.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest If I now remove xfprint and run "yum update" again with EPEL enabled, I get: ---> Package libxfce4util.x86_64 0:4.6.2-1.el5 set to be updated ---> Package libxfcegui4.x86_64 0:4.6.4-1.el5 set to be updated ---> Package xfce4-settings.x86_64 0:4.6.5-3.el5 set to be updated --> Processing Dependency: libexo-0.3.so.0()(64bit) for package: xfce4-settings ---> Package xfconf.x86_64 0:4.6.2-3.el5 set to be updated --> Running transaction check ---> Package exo.x86_64 0:0.3.107-2.el5 set to be updated --> Processing Dependency: xfce4-doc for package: exo --> Running transaction check ---> Package xfce4-doc.x86_64 0:4.6.2-3.el5 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: xfce4-settings x86_64 4.6.5-3.el5 epel 324 k replacing xfce-mcs-manager.x86_64 4.4.2-1.el5.centos xfconf x86_64 4.6.2-3.el5 epel 152 k replacing libxfce4mcs.x86_64 4.4.2-1.el5.centos Updating: libxfce4util x86_64 4.6.2-1.el5 epel 122 k libxfcegui4 x86_64 4.6.4-1.el5 epel 351 k Installing for dependencies: exo x86_64 0.3.107-2.el5 epel 1.8 M xfce4-doc x86_64 4.6.2-3.el5 epel 219 k Transaction Summary ================================================================================ Install 4 Package(s) Upgrade 2 Package(s) This will update the packages as described. I provided this listing to hopefully provide a better picture of which packages are obsoleted by other packages.

2 1

Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03)
by Honza Horak 03 Dec '14

03 Dec '14

Initial content: * there were concerns what will happen with downstream collections already in git.c.o -- we'll let the existing SCLs as they are now, at least for beginning * the sig can/could/should provide them as a build (not priority for beginning) * we should see what the biggest consumers need -- openshift origins or foreman * since there is quite big demand for php and mariadb, we will begin with those two collections New scl-utils: * next version of scl-utils will offer environment modules, but it is not ready so far Access to git/koji: * since nobody objected against proposed git structure, we'll start with what is proposed at https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal * in order to start we need to submit a bug with login, gpg public key, email and request git/koji access for both services in parallel * in koji, alphacc is executioner on the koji setup, but mikem, imcleod_ and MerlinTHP might be able to help as well Bug reporting: * we do not know how to track bugs so far Full meeting log attached. Conversation will continue at https://www.redhat.com/mailman/listinfo/sclorg. Honza

1 0

Switching to centralized authentication for centos.org infra (aka FAS vs IPA)
by Xavier Lamien 02 Dec '14

02 Dec '14

Greetings folks, As the principal FAS upstream, I would like to help you guys out making - as much as possible - (the right?) move by having the right information. First of all, let's start by a short FAS introduction. FAS has been designed to be community oriented by providing to the community a way to operate by itself through teams management (i.e group membership/management). As a result, our web interface has to be more than just an administrative interface to manage users & groups like other does. I recommend to go read more about it at https://admin.fedoraproject.org/accounts/about before go further. While keeping the openness, we also added: 1. A plugin Interface which let you add any new feature Plugin we had developed: * asterisk (no longer in prod however the plugin still is maintain) * yubikey (some of our group requires their members to have a key to access bound hosts) * OTP 2 factor auth (in a branch) 2. A non-standard API (current master) which let registered people and/or 3rd parties (from login mechanism) to read-only from FAS. Next is, my feedback after reviewed the wiki page and previous msg: >> project URL The project is mainly active on github (fedorahosted.org has been set as backup) v2: https://github.com/fedora-infra/fas v3.0: https://github.com/fedora-infra/fas/tree/FAS_3.0 >> packages available natively in the distro We do provide rpm's for rhel (e.g. http://infrastructure.fedoraproject.org/6Server/x86_64/fas-0.10.0-5.el6.noa… ) FAS v3 package will be in distro as it will be no Fedora project specific. >> multi-master replication Is this our we can replicate FAS from a master image? I really didn't get that one. If someone could explain it to me, that would be great. >> kerberos support: Not supported at this time. We do think of it for a v3.xx though. But it's not in my priority list unless someone is interesting to work on it. >> LDAP support: FAS v2: no. FAS v3.2: yes however, the LDAP support will be for group and people management. We will keep the DB as FAS is not about user and group management only. >> It's more or less a "Users CMDB" and cron jobs/scripts are creating/removing/modifying users/groups locally on each managed system. Naa, we have a fas-client which actually does the job to synchronize accounts on hosts. fas-client has been cron'd as the v2 is a non-daemon tools. We do have a daemon option though that listen to fedmsg and update hosts on demand. However, we set up a push-mode into Fedora infra. >> Mainly written to discuss with the fedmsg bus, and so targetting all Fedora Applications FAS has not been written to talk to 3rd parties (as stated in introduction). fedmsg cames few years after FASv2 launch. fedmsg is for FAS just another notification mechanism. >> Written for one project It has been the case for quite a while before I started work on FAS. For the record, I maintain the RPM Fusion infra and are using FAS there as well. even though this is related to fedora project, RPM Fusion are not providing the same level of services and doesn't have the same team structure (we don't use license agreement feature, nor asterisk's one, nor bugzilla feature atm). >> but we are working on a new fas 3 version that will use flask. Naa.. FAS 3 is a pyramid app. >> I guess it would be easier for everybody too, as just for today I've read that FAS3 would be in fact based on IPA so not on the actual FAS setup Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need as stated in introduction. However, we may look at their kerberos and directory server implementation as a plugin for FAS. If you have any question which are not answered here, please feel free to ask. Also, as Kevin said, the v3 is being writing and will come up with lot of features so question here are much appreciate ;) - Xavier

3 3

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel December 2014