devel

devel@lists.centos.org

4 participants
4640 discussions

Re: [CentOS-devel] CentOS 7 and release numbering
by Philip Mather 08 Jun '14

08 Jun '14

Morning all, I have to concur with Trevor and Kay on a lot of points... > The more CentOS feels exactly like "RHEL - but without > support", the more people understand it and take stock. There's an inevitable amount of trepidation around any change in direction from a Community Project and the current changes for CentOS are pretty significant, it seems wise to keep a clear and distinct link between CentOS and RHEL to allay any such concerns. In any "What does this mean to us?" conversation it would be very soothing to be able to say something like "Well, we'll move from CentOS 6.$x to 7.$y and that will continue to maintain compatibility just as before but the community will also be doing $z as well etc...". > Seems better to work around issues with the RHEL versioning scheme than to & > If the SIGs need a versioning scheme for the layers on top of the base > o/s then the new naming scheme sounds good for those but the core o/s, I > believe, should stick with mirroring upstream release numbers. At $work we do actually use a %YYYY%MM postfix in our Spacewalk set-up to keep monthly snapshots and I think the idea in the abstract is a good one (although YYYYMM is specifically excluded from ISO8601 for clarity reasons). However we add the date ourselves "independently", is there any reason the SIGs couldn't use the -$TAG in the same way? Allowing the core to remain unambiguously equivalent. It might even allow different SIGs to try different formats/options, find the best and then transfer control of the -$TAG format back up-stream to the CentOS Project centrally if there's agreement and then around(?)-stream to RedHat themselves? It could save their support guys any confusion of the future RHEL9 with the truly legacy "Red Hat Linux 9", a point I vaguely remember someone mooting about 7. :^) -- Regards, Phil

1 0

brand hunting utility
by Kay Williams 05 Jun '14

05 Jun '14

I've written a small utility (brand-hunter.py) to help with tracking down branding issues. It does the following: * accepts a list of srpms to search (if no srpms are listed, all srpms are searched) * downloads the srpms from ftp.redhat.com (across all rhel7 srpm repos) * extracts srpm content, including any bz2 or gz tarfiles. * searches text files (in multiline mode) for the pattern '[Rh][Ee][Dd]\s?[Hh][Aa][Tt]' * searches for any binary files * writes a list of issues (by file and line) to an issues.txt file (per srpm) * writes a noissues.txt file listing any srpms for which no issues were found. If folks are interested, please let me know a location where I can make the utility available. I ran it across the first 100 srpms (by yum sort order) and found only 7 srpms with no issues: GreSQL-4.0-9.el7.src SOAPpy-0.11.6-17.el7.src akonadi-1.9.2-4.el7.src ant-antunit-1.2-10.el7.src aopalliance-1.0-8.el7.src apache-commons-exec-1.1-11.el7.src apache-parent-10-14.el7.src The other 93 files had a range of issues, the most common of which are - * Redhat.com email addresses in patch files or author lists * Red Hat copyright statements * Binary files (of any kind, right now the utility flags them all as potential issues) The utility can be made smarter, say to ignore srpms with only redhat email addresses or copyright statements. But exclusions like these would be want to be done on a case by case bases, I imagine. Kay

6 11

Branding hunt
by Karanbir Singh 05 Jun '14

05 Jun '14

There are three things that we are trying to achieve in the branding hunt. In priority order these are : 1) To remove Red Hat TM's so as to meet their requirements and guidelines 2) To establish the CentOS Branding and identity 3) To remove ambiguity downstream as to where and what the code represents. This includes replacing strings that brand a component to be a part of RHEL. eg: if something says 'the xxxx for Red Hat Enterprise Linux' we would replace that to say 'the xxxx for CentOS Linux' Some notes to keep in mind while you go through stuff to check for branding issues : a) we are not trying to replace (c) Red Hat, or things where it says its Red Hat influenced, like the 'gcc -v' string b) Even if someone has reported a component as checked, please check it again - more +1's to a patch, or to a whitelist request, or to a blacklist request help increase confidence in the overall end result. c) please also install and check in the GUI, sometimes applications About box's will have the Red Hat shadowman logos that we need to usually replace. d) When in doubt, feel free to reach out Getting in touch : During the entire Branding hunt run, we will be available on #centos-devel / irc.freenode.net as well as the centos-devel list ( http://lists.centos.org/ ), feel free to reach out with comments, suggestions etc. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

7 8

The Branding Hunt - howto
by Karanbir Singh 03 Jun '14

03 Jun '14

hi Here is what's happening at the moment : 1) All the srpms published so far from RHEL are being imported into git repos, and brought into git.centos.org to be hosted under 'The CentOS Linux' group. 2) CentOS-5, CentOS-6 and CentOS-7 content will be hosted in 'c5', 'c6', 'c7' branches, with no content in master, other than a readme file pointing to the branches. Only '7' content being imported right now, we will try and retrofit the 5 and 6 content in the coming weeks. 3) there are components for all the distro pieces in bugs.centos.org already ( if not, please shout and someone will create them ) This is how we can run the branding hunt best : A) find a component that needs a patch B) clone the git repo that matches the srpm name that component came from. eg: git clone https://git.centos.org/git/distro!kernel.git C) create a patch for what you want the change to be D) make sure you also add a patch to the .spec file with your name and your email ID, this is what will get credited with the change E) open an issue report at bugs.centos.org, against Project: CentOS-7 and component that you want to patch. Write up details, attach patch. F) Goto A What we also need to do is establish a whitelist of components that people have looked at and found nothing. Please dont blanket assume that things like lib* or perl* dont need changes, only consider whitelisting code you have physically checked using reasonable means. For these things, please also open issue reports at bugs.centos.org and mention Whitelist in the subject of the issue report, again selecting CentOS-7 as the Project and the component name as required. Another thing to keep in mind with the whitelist is that its OK to check stuff other people might have already checked, the more whitelist reports we get, the better is the overall confidence in getting it in. If you need to patch a binary component, dont do a binary diff - just attach the new blurb that needs replacing in and mention the blurb that needs to go, we will try and automate that. Questions, reports, comments : come find us in #centos-devel on irc.freenode.net and centos-devel list ( http://lists.centos.org/ ). Also, keep in mind that the git repos are only going to be online at git.centos.org in about 8 hrs to 12 hrs time ( midday UTC June 3rd ), in the mean time you can still start off by consuming srpms from here : http://ftp.redhat.com/pub/redhat/rhel/rc/7/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 1

Kpatch in C7
by Karanbir Singh 03 Jun '14

03 Jun '14

hi, Wondering if anyone has looked at kpatch as yet, and if thats something we should try and get included in the CentOS Seven release. From what I can tell its going to be included in RHEL7. For those who dont know what it is : it lets you patch a running kernel, with a very simple build process and I-am-not-clear-what-the-delivery process might be, perhaps rpms itself. And for the lazy, I've done the search, here are urls to get you started: http://rhelblog.redhat.com/2014/02/26/kpatch/ and https://github.com/dynup/kpatch and http://lwn.net/Articles/597123/ There is even a list for it : http://www.redhat.com/mailman/listinfo/kpatch We dont have any code in the CentOS build process, so we'd need to come up with something ( standalone is fine ). -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

secure boot comments
by Karanbir Singh 02 Jun '14

02 Jun '14

hi Guys, Working through the mechanics of getting secure boot setup and running - and was wondering what everyones' thoughts are on that. Initially this would just be for CentOS-7, and we can later see if we want to also include CentOS-6 content ( although, we'd need grub2, afaict ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Next Cloud Instance SIG meetup
by Karanbir Singh 02 Jun '14

02 Jun '14

hi everyone The next meetup for the Cloud Instance SIG is scheduled for 16:30 UTC on the 2nd July 2014 at #centos-devel @irc.freenode.net At this meeting, I am hoping to demo the image building process, the automation around it, the kickstart repos around it and how people can consume this service. The setup works to build docker images, HVM images and AMI's delivered via various fileformats ( tar, qcow2, vmdk, raw ); The intention is to iterate over this setup and eventually get to a point where this becomes, curated by the Cloud Instance SIG, the official CentOS image build and delivery mechanism. Everyone is welcome to come along and join. Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 4

CentOS-7 LiveMedia content
by Karanbir Singh 28 May '14

28 May '14

hi guys, not sure how many people saw Fabian's post at http://seven.centos.org/ about his work on the LiveCD/DVD media for the upcoming CentOS-7 release; he's been working on the rhel7rc tree's till we get the CentOS-7rc tree's up ( which should happen in a few days time ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Reminder: VoIP SIG Hangout today Feb 13, 16:00 UTC
by Patrick Laimbock 28 May '14

28 May '14

Hi, Reminder: as previously announced on the centos-devel list, the VoIP SIG Hangout will be today Feb 13 at 16:00 UTC [0]. For more information how to join the hangout on Google+ or follow it on Youtube please check http://wiki.centos.org/OfficeHours Nothing set in stone but some of the things open for discussion are the scope of the VoIP SIG, the goal, the target audience, the deliverables, content distribution and lets not forget the actual proposal. It's also helpful to get an industry perspective, how to make the production side easier and facilitate processes that improve the usability of CentOS in the VoIP sector. Best regards, Patrick Laimbock [0] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140213T16&am=30

3 8

schedule based updates
by Karanbir Singh 28 May '14

28 May '14

hi, this is following on from the last Cloud Instance SIG meeting - the idea that we should be doing image updates was proposed, but I dont believe we decided on a time frequency of these builds. We can potentially do nightly builds and push them to ci.dev.centos.org, so if people want to really get a nightly snapshot they can. However, for most production requirements it makes sense to have these builds refreshed on a pre-determined schedule. Should we then be doing these weekly ? monthly ? When there is a major security issue ? Who decides its big-enough-an-issue ? This would then include container, VMs and cloud instance images. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

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