A number of people seem to not like the idea of gnome3 on the desktop for EL7, instead looking for the familiar gnome2 feel. I’ve taken a run at building MATE on the el7 beta and it looks pretty good overall. Over the next few days I’d like to sit down with some of the interested parties to discuss the best way to move forward with this as perhaps the beginning of the “Desktop SIG”.
In the interest of preparing for the el7 release, I’ve decided to attempt to migrate my primary machine to the el7 beta. For the most part this seems like it will be a reasonably easy transition, though admittedly I play with fedora frequently so the gnome2 to gnome3 transition is something I’ve already handled. If you find that you absolutely must have the wobbly windows, and desktop cube effects which are available in el6 then you’re in luck. All you have to do is transition from gnome to KDE, where these features are alive and well.
Apart from the gnome adjustment, there are a few things that I use regularly which just aren’t in the beta. Nearly all of these packages can rebuild cleanly for el7, using mock and the f19 srpms. For me these packages were transmission, pidgin-otr, thunderbird and its assorted plugins. The ‘fedora’ chrome packages google offers work flawlessly as well.
I was even able to get skype working in the el7 beta reasonably easily. The fact that skype is 32bit only complicated things slightly, as I had to borrow qt-mobility.i686 and qtwebkit.i686 from fedora to deal with the install dependencies. Once the i686 sig build of el7 is ready for additional packages, this rpm abuse shouldn’t be needed any longer.
I’ve been asked already about posting the rpms that I’ve built for the 7 beta, but I don’t want to do this. I don’t have an interest in maintaining them long-term, and I’m certain they’ll end up in epel or another repository shortly.
There has been reasonable interest in the i686 builds for CentOS-7. And we also need some i686 components for the x86_64 multilib payload.
As a step-1 of the process, we are going to try and workout how much of the published sources built on i686, bootstraping the builds from Fedora-19/i686 and then rebuilding onto itself. The targets setup for that are c6.99.00 ( bootstrap from f19 ) and c6.99.01 ( build over itself ). Builds for c6.99.00 are now running, you can track status at http://lists.centos.org/pipermail/centos-build-reports/2014-January/ - with 9 build workers running, I expect the build round to be over in just over 24 hrs.
Once that is done, we will move to c6.99.01, and fix build failures and address specific issues. For the .00 builds, were just building blind to get some binary code into the build roots, the real QA stuff will only happen into the 01 builds and onto the 02 ones.
Packages for the el7 beta are starting to show up in the EPEL repository. If you’ve been holding off looking at the beta because there were some ‘required’ packages missing, you might want to see what’s available now.
We’ve now got a public mailing list up at http://lists.centos.org/mailman/listinfo/centos-build-reports ; all build reports for the CentOS-7 src to binary builds will be posted there, including the fail and success reports. All fail reports will come with log file snippets as well as mock configs and the environ they were attempted in.
The list is readonly, with posts only allowed by the builder. All replies and followup conversations about the builds should be directed to the centos-devel list ( http://lists.centos.org/mailman/listinfo/centos-devel )
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.
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 ).
Know what it takes to build some of these ?
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.
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.
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.