devel

devel@lists.centos.org

5 participants
4641 discussions

Getting started on contributing to CentOS
by Gow Tham 18 Apr '15

18 Apr '15

Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg

2 2

CentOS Atomic: json consolidation
by Jason Brooks 16 Apr '15

16 Apr '15

At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa… Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com

2 1

Storage SIG Meeting 17-April-2015 15:30 UTC
by Lalatendu Mohanty 16 Apr '15

16 Apr '15

Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala

1 0

nss build failure - Just an FYI to folks who may be rebuilding.
by Jim Perrin 16 Apr '15

16 Apr '15

One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

1 0

"CentOS.devel"
by Colin Walters 15 Apr '15

15 Apr '15

For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives)

11 16

Re: [CentOS-devel] Hosting CentOS bugs on RH bugzilla
by Marcin Dulak 15 Apr '15

15 Apr '15

Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin

8 10

triggering external actions from koji builds
by Karanbir Singh 15 Apr '15

15 Apr '15

hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 5

Welcoming Brian to CentOS Engineering Team at Red Hat
by Karanbir Singh 14 Apr '15

14 Apr '15

hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 3

Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA)
by Brian Stinson 14 Apr '15

14 Apr '15

Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian(a)bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/

2 2

compiling on EL 7.x, using -fsanitize=xxx
by Fred Smith 13 Apr '15

13 Apr '15

Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) -----------------------------

2 2

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