xmlns:content="http://purl.org/rss/1.0/modules/content/"

	xmlns:wfw="http://wellformedweb.org/CommentAPI/"

	xmlns:dc="http://purl.org/dc/elements/1.1/"

	xmlns:atom="http://www.w3.org/2005/Atom"

	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"

	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"

	>

<channel>

	<title>Seven.CentOS.org</title>

	<atom:link href="http://seven.centos.org/feed/" rel="self" type="application/rss+xml" />

	<link>http://seven.centos.org</link>

	<description>News, views and reports on CentOS-7</description>

	<lastBuildDate>Tue, 07 Jan 2014 08:27:16 +0000</lastBuildDate>

	<language>en-US</language>

		<sy:updatePeriod>hourly</sy:updatePeriod>

		<sy:updateFrequency>1</sy:updateFrequency>

	<generator>http://wordpress.org/?v=3.8</generator>

	<item>

		<title>CentOSPlus kernel for .el7</title>

		<link>http://seven.centos.org/2014/01/centosplus-kernel-for-el7/?utm_source=rss&utm_medium=rss&utm_campaign=centosplus-kernel-for-el7</link>

		<comments>http://seven.centos.org/2014/01/centosplus-kernel-for-el7/#comments</comments>

		<pubDate>Mon, 06 Jan 2014 17:36:17 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=78</guid>

		<description></description>

				<content:encoded>There are two main roles offered by the centosplus kernel; one is to provide features that are disabled in the distro kernel and the other is to fix known issues by applying patches. The plus kernel for .el7 is now under development and can be followed in this bug tracker.

So far rebuilding the kernel with modified config file(s) seems straightforward — at least not as convoluted as it is in .el6.

A number of drivers have been removed / disabled in EL7beta compared to EL6.5 as seen in the EL7beta Release Notes. They are good candidates for the plus kernel. A user who needs the ath5k driver realized it wasn’t in the el7beta and rebuilt the kernel. This and other drivers will be included in the .el7 plus kernel.

At some point, a test version will be made available, so stay tuned. In the meantime, please file a request for features and propose bug fixes by opening a new bug tracker report.

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2014/01/centosplus-kernel-for-el7/feed/</wfw:commentRss>

		<slash:comments>0</slash:comments>

		</item>

		<item>

		<title>State of the build 20140104</title>

		<link>http://seven.centos.org/2014/01/state-of-the-build-20140104/?utm_source=rss&utm_medium=rss&utm_campaign=state-of-the-build-20140104</link>

		<comments>http://seven.centos.org/2014/01/state-of-the-build-20140104/#comments</comments>

		<pubDate>Sat, 04 Jan 2014 02:16:03 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=76</guid>

		<description></description>

				<content:encoded>This is what our to-build queues look like at the moment, note that they are by arch of the required resulting rpms ( so srpms that produce multi arch binaries will be listed twice ).

noarch/apache-commons-net-3.2-7.el7.src.rpm

noarch/args4j-2.0.16-11.el7.src.rpm

noarch/boost-1.53.0-14.el7.src.rpm

noarch/byteman-2.0.4-3.el7.src.rpm

noarch/cdi-api-1.0-9.SP4.el7.src.rpm

noarch/fftw-3.3.3-6.el7.src.rpm

noarch/fprintd-0.5.0-1.el7.src.rpm

noarch/gimp-help-2.8.0-7.el7.src.rpm

noarch/gstreamer-plugins-base-0.10.36-4.el7.src.rpm

noarch/istack-commons-2.17-2.el7.src.rpm

noarch/jansi-1.9-5.el7.src.rpm

noarch/jarjar-1.4-3.el7.src.rpm

noarch/javassist-3.16.1-8.el7.src.rpm

noarch/jboss-ejb-3.1-api-1.0.2-7.el7.src.rpm

noarch/jboss-interceptors-1.1-api-1.0.2-0.6.20120319git49a904.el7.src.rpm

noarch/jboss-jaxrpc-1.1-api-1.0.1-4.el7.src.rpm

noarch/jboss-servlet-3.0-api-1.0.1-6.el7.src.rpm

noarch/jboss-transaction-1.1-api-1.0.1-5.el7.src.rpm

noarch/jing-trang-20091111-12.el7.src.rpm

noarch/json-c-0.11-1.el7.src.rpm

noarch/jsr-311-1.1.1-4.el7.src.rpm

noarch/libbase-1.1.3-8.el7.src.rpm

noarch/libfonts-1.1.3-11.el7.src.rpm

noarch/libformula-1.1.3-8.el7.src.rpm

noarch/libloader-1.1.3-7.el7.src.rpm

noarch/librepository-1.1.3-7.el7.src.rpm

noarch/libserializer-1.1.2-8.el7.src.rpm

noarch/maven-plugin-tools-3.1-14.el7.src.rpm

noarch/maven-site-plugin-3.2-5.el7.src.rpm

noarch/pentaho-libxml-1.1.3-8.el7.src.rpm

noarch/perl-Test-DistManifest-1.012-4.el7.src.rpm

noarch/plexus-compiler-2.2-5.el7.src.rpm

noarch/plexus-containers-1.5.5-12.el7.src.rpm

noarch/sac-1.3-15.el7.src.rpm

noarch/sisu-2.3.0-9.el7.src.rpm

noarch/stax-ex-1.7.1-4.el7.src.rpm

noarch/tomcat-7.0.40-2.el7.src.rpm

x86_64/at-3.1.13-12.el7.src.rpm

x86_64/compat-dapl-1.2.19-2.el7.src.rpm

x86_64/dapl-2.0.34-1.el7.src.rpm

x86_64/esc-1.1.0-25.el7.src.rpm

x86_64/fprintd-0.5.0-1.el7.src.rpm

x86_64/grilo-plugins-0.2.6-1.el7.src.rpm

x86_64/gstreamer-plugins-base-0.10.36-4.el7.src.rpm

x86_64/libreoffice-voikko-3.3-3.el7.src.rpm

x86_64/pyliblzma-0.5.3-8.el7.src.rpm

x86_64/scl-utils-20130529-1.el7.src.rpm

x86_64/xvattr-1.3-24.el7.src.rpm

x86_64/zsh-5.0.2-3.el7.src.rpm

Know what it takes to build some of these ?

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2014/01/state-of-the-build-20140104/feed/</wfw:commentRss>

		<slash:comments>0</slash:comments>

		</item>

		<item>

		<title>A bigger pool and more fish</title>

		<link>http://seven.centos.org/2014/01/a-bigger-pool-and-more-fish/?utm_source=rss&utm_medium=rss&utm_campaign=a-bigger-pool-and-more-fish</link>

		<comments>http://seven.centos.org/2014/01/a-bigger-pool-and-more-fish/#comments</comments>

		<pubDate>Thu, 02 Jan 2014 00:47:00 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=72</guid>

		<description></description>

				<content:encoded>A fallout of how we are setup, where we are setup and what constraints we worked under : only a very small number of people have been able to request builds, look at output, make changes to the build environment and the process around it.

One of the big goals for the CentOS Linux 7beta effort is to try and fix that. And over the last few days, I’ve pushed code and make process changes that now allow anyone on the CentOS-QA team to request builds, make changes to the mock templates, manage per-package build environments, modify hints and process templates.

Given that the content isnt de-branded and we’ve not got the local mod’s in place as yet ( or even the overall distro blacklist ), cant make the build-result public as yet, but thats on the agenda.

Also on the agenda is a public git repo that contains all the metadata and mock configs used in the build process, with a merge-request-process that allows anyone to come and help. It wont be done tomorrow, but it should be done and in place, working by the end of Jan; And unless Red Hat pull something dramatic, well in time before the EL7 release.

- KB

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2014/01/a-bigger-pool-and-more-fish/feed/</wfw:commentRss>

		<slash:comments>2</slash:comments>

		</item>

		<item>

		<title>EPEL-6 buildrun on RHEL7b1</title>

		<link>http://seven.centos.org/2014/01/epel-6-buildrun-on-rhel7b1/?utm_source=rss&utm_medium=rss&utm_campaign=epel-6-buildrun-on-rhel7b1</link>

		<comments>http://seven.centos.org/2014/01/epel-6-buildrun-on-rhel7b1/#comments</comments>

		<pubDate>Thu, 02 Jan 2014 00:39:00 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=69</guid>

		<description></description>

				<content:encoded>One of the big challenges we had while building CentOS-6 was to do with scaling the builds. While resources existed, I was unable to get more than 3 ( and in some cases, like perl  modules that build with -j1, upto 5 ) concurrent builds. I’ve been quite keen to solve that problem and a bunch of changes, locking in the pre-chroot-build and locking-post-build code had me thinking we could get upto somewhere near the 32 concurrent builds mark.

Based on some very rudimentary maths, 32 concurrent builds will allow us to build/rebuild the distro in just under a day, including the tests, the media and the staging process. In other words, changes to metadata in the build environment would not slow things down for more than a day or so.

Because el7b1 itself isnt quite ‘done’ yet, I cant use that as a benchmark – so it was EPEL6 built against the el7b1 content as released upstream; You can read more about that here : http://www.karan.org/blog/2014/01/02/an-epel-build-in-rhel7b1/ and I really don’t recommend people use that content for anything other than academic purposes ( figure out what broke and why …. maybe use some of that on their el7b1 test installs etc ).

The real outcome was that I still cant scale beyond fifteen concurrent workers, without losing the ability to chain builds through; or not use just-built content in subsequent builds. The EPEL6 churn took just over a day, but this was just for the source -> binary conversion ( where and when it did build );  extrapolating back from there it means we should be able to build el7b1 in just over a day and a half, once everything works and we know that the metadata around the builds is good – were not there yet, but getting close.

Given that the number of long running builds has reduced from el6 to el7, the drop in numbers from thirty two to fifteen concurrent builds isn’t that much of a problem – plus, given that we have a much more open process, with the potential for a lot more people to get involved, we should have the environment issues resolved faster.

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2014/01/epel-6-buildrun-on-rhel7b1/feed/</wfw:commentRss>

		<slash:comments>0</slash:comments>

		</item>

		<item>

		<title>t_functional update</title>

		<link>http://seven.centos.org/2013/12/t_functional-update/?utm_source=rss&utm_medium=rss&utm_campaign=t_functional-update</link>

		<comments>http://seven.centos.org/2013/12/t_functional-update/#comments</comments>

		<pubDate>Thu, 26 Dec 2013 21:56:07 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=60</guid>

		<description></description>

				<content:encoded>So, the t_functional stack should now be able to use ’7′ to distinguish between releases in various tests (as it allready does for 5 and 6). This has allready been added to the test for vconfig. So 45 tests remain to be fixed.

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2013/12/t_functional-update/feed/</wfw:commentRss>

		<slash:comments>2</slash:comments>

		</item>

		<item>

		<title>t_functional status against el7b1</title>

		<link>http://seven.centos.org/2013/12/t_functional-status-against-el7b1/?utm_source=rss&utm_medium=rss&utm_campaign=t_functional-status-against-el7b1</link>

		<comments>http://seven.centos.org/2013/12/t_functional-status-against-el7b1/#comments</comments>

		<pubDate>Thu, 26 Dec 2013 17:01:14 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=55</guid>

		<description></description>

				<content:encoded>So, Christoph blogged about t_functional and how it is used for CentOS QA. Here is the first status of the actual t_functional stack against el7b1 : the following tests need to be adapted to work on el7 (I’m talking about our QA test scripts, not our build results !) :

p_amanda:FAIL

p_anaconda:FAIL

p_arpwatch:FAIL

p_busybox:FAIL

p_centos-release:FAIL

p_chkconfig:FAIL

p_cron:FAIL

p_diffutils:FAIL

p_dovecot:FAIL

p_file:FAIL

p_freeradius:FAIL

p_grub:FAIL

p_gzip:FAIL

p_httpd:FAIL

p_initscripts:FAIL

p_iptables:FAIL

p_iptraf:FAIL

p_iputils:FAIL

p_jwhois:FAIL

p_kernel:FAIL

p_logwatch:FAIL

p_lsb:FAIL

p_lynx:FAIL

p_mailman:FAIL

p_mysql:FAIL

p_network:FAIL

p_ntp:FAIL

p_openssh:FAIL

p_passwd:FAIL

p_php:FAIL

p_postgresql:FAIL

p_procinfo:FAIL

p_python:FAIL

p_rsync:FAIL

p_ruby:FAIL

p_sendmail:FAIL

p_squid:FAIL

p_squirrelmail:FAIL

p_tcpdump:FAIL

p_tftp-server:FAIL

p_tomcat:FAIL

p_traceroute:FAIL

p_vconfig:FAIL

p_webalizer:FAIL

p_yum:FAIL

p_yum-plugin-fastestmirror:FAIL

So if you want to help, be sure to contribute to the t_functional QA stack by fixing/writing those tests to be el7 compatible . Happy holidays and QA’ing !

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2013/12/t_functional-status-against-el7b1/feed/</wfw:commentRss>

		<slash:comments>2</slash:comments>

		</item>

		<item>

		<title>State of the build 20131224</title>

		<link>http://seven.centos.org/2013/12/state-of-the-build-20131224/?utm_source=rss&utm_medium=rss&utm_campaign=state-of-the-build-20131224</link>

		<comments>http://seven.centos.org/2013/12/state-of-the-build-20131224/#comments</comments>

		<pubDate>Tue, 24 Dec 2013 12:18:17 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=51</guid>

		<description></description>

				<content:encoded>RHEL7b1 is composed of 2520 srpms; Of these, some are arch specific to arch’s we are not building (yet).

The x86_64 distro is made up of 8,520 binary rpms. Of these, 2,863 are noarch rpms and 1,919 are 32bit multilib. Leaving us with 3,738 x86_64 rpms that need to be built. Lets assume that building a clear x86_64 distro is our first goal here ( its not, but things are simpler with that assumption ).

As round-1 of the build cycle, we built all 2520 srpms against f19/32bit and then all of them again against f19/64bit; I use this result set as a backstore, to borrow from when we need to either break a dependency loop, or satisfy an interim build requirement locally. These packages are not otherwise a part of the regular buildroots used for round-2.

Round-2 is then a mass build attempt against r7b1/32bit and r7b1/64bit. Of these, nothing built against r7b1/32bit since large chunks of packages needed, even for the baseline buildroot are not published upstream. And needing to borrow from the f19/32bit backstore meant almost using a f19 buildroot, which isnt ideal. So lets put that aside for the time being.

The second part of round-2 was the x86_64 build attempt against r7b1/64bit. The results are a bit more promising there :  85% of the packages build. But only about 75% of those that build, look like the ones shipped by Red Hat as the 7b1 repos. I’m using percentages here, since using exact numbers for built-matched takes away from the aim of getting to complete.  Now adding in the noarch builds, we get to : 5636 of 8520 built. Taking away the 1919 that are i686 rpms, we get a deficit of 965 that failed completely. These 965 represent 122 source rpms.

And this 122 set is going to be our next target. Alongside, I am going to start working on the blacklist/whitelists so we can start making the build roots public. Look for more info on that in the coming days, along with how everyone can contribute towards the 7 build effort.

- KB

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2013/12/state-of-the-build-20131224/feed/</wfw:commentRss>

		<slash:comments>2</slash:comments>

		</item>

		<item>

		<title>preventing gnome3′s initial setup</title>

		<link>http://seven.centos.org/2013/12/preventing-gnome3s-initial-setup/?utm_source=rss&utm_medium=rss&utm_campaign=preventing-gnome3s-initial-setup</link>

		<comments>http://seven.centos.org/2013/12/preventing-gnome3s-initial-setup/#comments</comments>

		<pubDate>Mon, 23 Dec 2013 21:48:36 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=47</guid>

		<description></description>

				<content:encoded>The first time a user logs into the default desktop for the rhel7 beta,  they’re prompted to set a language, add online accounts, and dropped into a help menu right from the start. While this might be nice for brand new users, it’s certainly not ideal for everyone.

Turns out there’s a very simple way to prevent this annoyance from spreading further than it needs to.

mkdir ~/.config

echo "yes" >> ~/.config/gnome-initial-setup-done

Alternatively, if you want to do this for every new user on your system rather than dealing with it one at a time, simply drop the .config directory and file into /etc/skel before you create your new users.

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2013/12/preventing-gnome3s-initial-setup/feed/</wfw:commentRss>

		<slash:comments>0</slash:comments>

		</item>

		<item>

		<title>NetworkManager and bridging</title>

		<link>http://seven.centos.org/2013/12/network-manager-and-bridging/?utm_source=rss&utm_medium=rss&utm_campaign=network-manager-and-bridging</link>

		<comments>http://seven.centos.org/2013/12/network-manager-and-bridging/#comments</comments>

		<pubDate>Fri, 20 Dec 2013 15:46:02 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=37</guid>

		<description></description>

				<content:encoded>In previous iterations of NetworkManager, it was really only useful if you were dealing with wireless networks. Anything involving a bridge meant removing the device from NetworkManager, and manually configuring the network.

A fair amount of work has been done to make NetworkManager more friendly to bridged devices, however it’s still far from perfect.    My experiences so far:

There isn’t an intuitive way to create a bridge in the NetworkManager gui.

Configuring the bridge manually, and leaving control of the devices with NetworkManager works. I tested this using bridged network devices and virtual machines in virt-manager.

With a manually configured bridge, the status icon in gnome is confused at best. Do not rely on it to provide an accurate status of your network.

The screenshot below should demonstrate the confusion to some extent. I wouldn’t expect the ‘Wired’ connection to show up, as it’s a slave to the bridge. Both the virbr0 and the vpn show as off, even though both are active and in use.

At this point the best course of action for anyone who needs a bridge is simply to remove NetworkManager from the equation. Since this is already current practice, it’s not really a deviation for folks tracking 6->7 differences.

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2013/12/network-manager-and-bridging/feed/</wfw:commentRss>

		<slash:comments>2</slash:comments>

		</item>

		<item>

		<title>State of the build 20131219</title>

		<link>http://seven.centos.org/2013/12/state-of-the-build-20131219/?utm_source=rss&utm_medium=rss&utm_campaign=state-of-the-build-20131219</link>

		<comments>http://seven.centos.org/2013/12/state-of-the-build-20131219/#comments</comments>

		<pubDate>Thu, 19 Dec 2013 09:53:46 +0000</pubDate>

		<dc:creator></dc:creator>

				<category></category>

		<guid isPermaLink="false">http://seven.centos.org/?p=39</guid>

		<description></description>

				<content:encoded>One thing that everyone is going to want to know about, or not, is the state of the CentOS-7 beta build. Yes, we are building it, slowly and making system changes as we need and adapting the buildsystems for the changes needed, but we are building it. I will try and do a short status update of this nature everytime we hit a benchmark, but at-least once a week from now till we are ‘done’.

At the moment the c7builder consist of 1 machine, 128GB ram, 4x1TiB sata’s and 4x64gb ssd, 48 cores. Its a nice machine, but its completely self contained. In the coming days I will expand this to include another similar machine.

So, are we there yet ? Not quite. 72 Failed builds, 388 Done, Lots to go.

remember this is run#1, things get better with every iteration of the build, and then we start looking at that failure reasons and working up from there.

Best news of the moment ? I am pleased to report that from run#2 onward, the build results, logs, configs and metadata of build will be published publicly allowing everyone to help, get involved and contribute! Stay tuned for more news on that in the coming weeks.

]]></content:encoded>

			<wfw:commentRss>http://seven.centos.org/2013/12/state-of-the-build-20131219/feed/</wfw:commentRss>

		<slash:comments>1</slash:comments>

		</item>

	</channel>

</rss>