devel March 2015

devel@lists.centos.org

63 participants
60 discussions

moving from gitorious
by Karanbir Singh 07 May '15

07 May '15

Hi, We have some of our content currently hosted on gitorious.org that we mirror from git.centos.org - the intention being that git.centos.org is still the authority, but people can use the easier contribution path at gitorious to build karma and then get direct git commit access at git.centos.org since gitorious is going away, what are everyone's thoughts to consolidating all of this external contribution path on github.com/CentOS - we already host a bunch of content there. 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

10 17

Fixing up Xfce for CentOS 7
by Toni Spets 01 May '15

01 May '15

Hello list, I've been in contact with Anders F Björklund (afb) earlier this week regarding the state of Xfce on CentOS 7 and in general in any supported EPEL release. What we discussed was what he has done in the past for his personal use and what are the things we would both agree on that should get some attention to make the experience better. Here are some initial things that we think are critical (give or take, Anders has his own list): 1. Packaging issues - comp group @xfce-desktop doesn't depend on @X Window System so it doesn't really work and has some wrong packages and some missing - @xfce-desktop depends on gdm instead of lightdm, we think it should do that instead - dejavu sans fonts are not a dependency and fonts are broken because of that - gtk-xfce-engine package is missing (EPEL7) 2. Branding issues - "Default" appearance theme is missing (requires gtk-xfce-engine, request sent to EPEL) - default background is blank (broken Fedora branding, patch submitted) - default icon set is wrong and broken (should be GNOME because "Fedora" doesn't exist on RHEL, patch submitted) There are more, but these are one of the first usability issues that you would hit when installing Xfce from EPEL 7. I have submitted bug reports with proposed fixes for the background issue, default theming issue and missing gtk-xfce-engine package: https://bugzilla.redhat.com/show_bug.cgi?id=1200988 https://bugzilla.redhat.com/show_bug.cgi?id=1200992 https://bugzilla.redhat.com/show_bug.cgi?id=1201124 Now, getting EPEL fixed up would be in general a good effort since it's shared between all derivatives of RHEL/CentOS and more people will get the base benefits. That said, there are two ways this SIG could be constructed: a) shim wrapper around EPEL to create a spin and possibly add some CentOS specific branding, give EPEL maintainer all the help we can to get the packages working, try push most if not all packaging work to EPEL b) completely replace EPEL by our own repo which has all the Xfce packages and anything we would want The A option depends on if the maintainer is willing to let us help as much as we want and would accept some of the changes we'd need. It would also imply the current EPEL maintainer(s) would continue maintaining and be our upstream or someone would join the EPEL folks as co-maintainers. The amount of initial work would be minimal compared to doing everything custom and as I said before, it benefits every RHEL derivative, including RHEL itself. We still need some SIG specific packages like CentOS specific branding and possibly our own default panel layout so it's not all upstream work. This approach might also be tad slower because we have an upstream and all packaging stuff except barnding would go through them. The B option gives us more power and could speed up the process a lot. We can select and backport the set of Xfce packages as fast as we can.Karanbin Singh was kind enough to provide some info about how CentOS SIGs work and what resources would be available (automatic builds, official SIG repos etc.) so all the backend stuff is there waiting to be untilized for this kind of SIG. However, this approach would be very CentOS specific and would require the SIG to be fairly active in maintaining the packages when our upstream (the Xfce project) makes point releases. I can say upfront that person wouldn't be me, so if someone is up to this after the initial sprint of work has ended, that would be something to consider. One more very important thing to note is that EPEL 7 is set to Xfce 4.10 and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we would need to stick with 4.10 unless the maintainer feels 4.12 upgrade would be possible, then it's a win for option A. The maintainer (or one of them) also maintains a 4.12 copr for F20 so I strongly believe he knows much more about Xfce packaging than me for one. If we do option B we could scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as a SIG would be the perfect place to get more up-to-date experience on top of stable core. I'm up for either one, it's up to what you other people would see as being more useful. Maybe both if there is enough interest? Fix EPEL for the greater good and still have our own SIG 4.12 stuff on top of it for CentOS only. Anyone into this except me and Anders? Ideas, suggestions? -- Toni Spets

8 16

Storage SIG Meeting 6-March-2015 15:30 UTC
by Lalatendu Mohanty 18 Apr '15

18 Apr '15

Greetings All! Time for another Storage SIG meeting [1] ( We are following a bi-weekly schedule) . But I forgot to announce it yesterday. Sorry for the inconvenience caused. Let me know if it is too late to announce the meeting (in that case we can cancel this meeting). We will be meeting in #centos-devel on Freenode. Agenda: #info Topic: Action items from previous meeting #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic: OpenAFS #info Subtopic: Ceph #info Subtopic: SCST #info Open Floor Thanks, Lala

3 5

including 3rd party repo release RPMs in Extras
by Carl George 10 Apr '15

10 Apr '15

Howdy, My name is Carl, and I'm a developer for the IUS Community repository. CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far. https://gist.github.com/cgtx/b854281462a18007f509 If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas. Carl George Rackspace RPM Development

8 17

Atomic release checklist
by Jason Brooks 07 Apr '15

07 Apr '15

As discussed in last week's meeting (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), I've put a CentOS Atomic release checklist in the wiki at: http://wiki.centos.org/Atomic/ReleaseManagement Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com

4 5

enhancing /etc/*-release
by Karanbir Singh 06 Apr '15

06 Apr '15

hi, We have spent a lot of time working out how best to work the /etc/centos-release file in order to satisfy most use cases. We've had a lot of positive feedback on the three digit release numbering that went into the first CentOS-7 release. And in the coming months, as the rolling builds onramp we will start seeing movement around those. This will also help address some points learned from the community during the 7.0.1406 cycle. We have also decided to split the /etc/redhat-release link to /etc/centos-release and use that as a way to better indicate what codebase the running CentOS Linux instance was derived from. Examples of what these files will look like in say March 2015 ( if .1 is released upstream by then ): ------------------- /etc/centos-release: CentOS Linux release 7.1.1503 (Core) /etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source) ------------------- The /etc/os-release file remains unchaged to indicate CentOS-7 as being the distro being consumed. We will however, be adding ABRT specific content to the os-release file once we have bugs.centos.org setup to accept abrt requests - and we have the required patched rolled out into the distro. These additions will have no impact on numbering reported via tools that consume /etc/os-release. The /etc/centos-release file will then evolve with every monthly release, with the updated file being pushed into updates repo. This implies if someone was to install from the March rolling build, their /etc/centos-release will already have 7.1.1503 and anyone having a previously installed machine, doing a yum update would see the same file drop in. The net result is an impact for new people installing from rolling build media ( and instance media like live images, cloud images, containers etc ). One installed or running, there is no change to how CentOS Linux has been in the past. You just get regular updates, and any machine, regardless of how it was installed and when, updated to the same point in time will have identical content. -- 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

14 27

CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08)
by Honza Horak 03 Apr '15

03 Apr '15

Unfortunately I'm not available this week on Wed, I'm sorry, so let's arrange the SCLo meeting the next week. Since we have DST in Europe already as well, let's change to 15:00 UTC, that should fit to out schedules the same as it did on non-DST. So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * sync-up on current status * propose some other topics:) Honza

3 4

Congratulations for selection in GSOC-2015
by Saket Sinha 02 Apr '15

02 Apr '15

Hi, I will like to congratulate the Centos Team for getting selected in GSOC 2015. Looking forward to work with them this summer. I have gone through the ideas listed on the centos ideas page and i am interested in working on "Rootfs build factory". http://wiki.centos.org/GSoC/2015/Ideas#rootfs-build-factory Regards, Saket Sinha

4 10

Re: [CentOS-devel] xapi on CentOS 6
by George Dunlap 01 Apr '15

01 Apr '15

KB / Jonathan / Others, One of our potential GSoC students, Guatam Malu, has proposed trying to include xapi packages in the "Xen in a Box" project. He's gotten packages of xapi building for CentOS 6.6 using XenServer's buildroot (see below). The only potential issue I see is about signing. As I understand it, xapi requires a newer version of ocaml than is available in C6. The XenServer buildroot includes (and I think builds) a newer version of ocaml; but (again I think) xapi is statically linked, so the new ocaml packages are only required for build, and not for runtime. At the moment Jonathan is trying to work with one of the other SIGs to get the necessary ocaml support; it's not clear when that will happen. Until that time, the only way to get xapi packages built in koji by the Virt SIG would be to also include the newer version of ocaml (and whatever other dependencies there are), which we'd like to avoid. So the question is: Do we need to have all the packages on "Xen in a Box" CD signed with the CentOS SIG key? If so, do we see any likelihood that this might be possible by July -- either having a suitable ocaml to build against in koji, or getting the packages built and signed some other way? Thanks, -George On Mon, Mar 30, 2015 at 7:03 PM, Gautam Malu <gautam.malu(a)research.iiit.ac.in> wrote: > Hi, > I am a masters student at IIIT Hyderabad. I have applied for gsoc 2015, for > xen in a box proposal. > As a part of my proposal,I want to deliver xapi repo which can be used to > build a custom installer ISO to install CentOS 6 + xen + xapi. > > > Here is my full proposal > http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/gautam_m… > > About building xapi packages for CentOS; I was able to build all xenserver > packages with xenserver build root. (https://github.com/xenserver/buildroot) > on CentOS 6.6 . This buildroot uses Xen4CentOS repo for xen packages, but it > uses custom repo for Ocaml(4.01). > > The Base repo for CentOS 6.6 have ocaml 3.11. This buildroot required Ocaml > 4.x. The gsoc would start in May end, if Ocaml 4.x packages are ready by > then, Those could be used to build xapi. > > Is there any plan to have xapi as part of virt SIG. > Is there any time-line for having ocaml 4.x packages in CentOS offical > repo. > > Best regards, > Gautam Malu

4 4

Who's up for a challenge?
by Justin Clift 30 Mar '15

30 Mar '15

Hi all, Any Koji experts around, who can give some pointers/assistance with the CentOS "Community Build System"? We're trying to automatically build a patched kernel RPM, when new kernel updates happen. (for the Storage SIG) When triggered, the build environment only has the stock/base kernel rpm though, and not the updated kernel one. :( Ideas? Regards and best wishes, Justin Clift -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel March 2015