devel December 2014

devel@lists.centos.org

38 participants
40 discussions

CBS/Infra Meeting 15-Dec-2014 14:00 UTC
by Brian Stinson 15 Dec '14

15 Dec '14

Hi All! Every other week we get together to talk about the status of the CentOS Community Build System[1]. We will be meeting on 14-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 (Ready for testing!) #info Topic: Building a package to provide the koji client config & cbs binary? #info Topic: Open Floor Cheers! Brian [1] http://cbs.centos.org/

2 2

Storage SIG Meeting 12-Dec-2014 15:30 UTC
by Lalatendu Mohanty 15 Dec '14

15 Dec '14

Greetings All! We have been working on Storage SIG for sometime now. We think it is time to get together with the community, talk and discuss about Storage SIG [1]. We will be meeting on 12-Dec-2014 15:30 UTC in #centos-devel on freenode. Agenda: #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic: OpenAFS #info Subtopic: Ceph #info Subtopic: SCST in Storage SIG? #info Open Floor _/Minutes from Previous meeting:/_ highlights from this meeting: * Lala offering to take up slack since Patrick is busy and take over running meetings moving forward -- to propose a meeting date/time slot on centos-devel list -- to establish where the meeting to take place ( most people seem to like irc and therefore #centos-devel might be an option ) Status Checks: * gluster is ready to move into testing, BLOCKED ON: sign and release process being implemented * openafs is making progress, using Fedora COPR for builds. Lala to interface with Andrew and JBillings to get them setup with koji access --- for now, build via SRPMS since git -> koji is not quite 100% --- openafs also needs conversation and consideration around building kmod's for multiple kernel versions, and to build/rebuild on every kernel release ( speak to Thomas, Mike and buildsys group for feedback ) --- openafs is not tested client + server side, contributors feel there should be -some- testing on both sides before we pass along confidence in builds to users Other * SCST folks are keen to join the effort, KB to introduce them into group [1] http://wiki.centos.org/SpecialInterestGroup/Storage Thanks, Lala #lalatenduM on Freenode

2 4

RFC: OCaml SIG
by Jon Ludlam 13 Dec '14

13 Dec '14

Hi all, I'd like to propose a new SIG for the OCaml language. OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4]. The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6]. A number of people have already agreed that they are interested and may be able to help (all CC'd): >From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/): - Anil Madhavapeddy - Thomas Gazagnaire >From Jane Street (https://www.janestreet.com/): - Yaron Minsky - Dominick LoBraico >From Citrix (https://www.citrix.com/): - Me - Euan Harris >From OCamlPro (http://www.ocamlpro.com/): - Louis Gesbert Comments? Jon [1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot

7 20

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel December 2014