devel

devel@lists.centos.org

2 participants
4652 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

CentOS SCLo SIG sync-up meeting on #centos-devel (2015-05-06)
by Honza Horak 06 May '15

06 May '15

SCLo SIG 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

1 0

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

GSoC projects and SIG meetings
by Karanbir Singh 01 May '15

01 May '15

hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 4

RH patches v/s vanilla docker in CentOS
by Lokesh Mandvekar 30 Apr '15

30 Apr '15

I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD

8 18

[SIG Harden] Personal goals
by leam hall 29 Apr '15

29 Apr '15

My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission <http://leamhall.blogspot.com/>

4 9

[Cloud SIG] RDO/OpenStack test day, May 5th, 6th
by Rich Bowen 29 Apr '15

29 Apr '15

For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://rdoproject.org/

1 0

Using gcc -fsanitize=thread on C7
by Fred Smith 28 Apr '15

28 Apr '15

Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) -----------------------------

2 1

Fwd: RDO (Cloud SIG) meetup at OpenStack Summit
by Rich Bowen 28 Apr '15

28 Apr '15

FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen <rbowen(a)redhat.com> To: rdo-list(a)redhat.com <rdo-list(a)redhat.com> I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://rdoproject.org/

1 0

CentOS7 Vagrant box with container runtime and tools
by Lalatendu Mohanty 28 Apr '15

28 Apr '15

Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala

2 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