[elrepo-devel] ELRepo packages for EL6

[Phil Perry]

On 12/07/10 21:59, Farkas Levente wrote:
> On 07/10/2010 01:27 PM, Phil Perry wrote:
>> On 09/07/10 08:46, Farkas Levente wrote:
>>> On 07/08/2010 10:52 PM, Akemi Yagi wrote:
>>>> Hi all,
>>>>
>>>> Now that RHEL6beta2 is out, we would like to get ready for the release
>>>> of ELRepo packages for the EL6.  We (mostly Phil and Alan) have done
>>>> some ground work and have done some test-build of a few packages.
>>>>
>>>> Do you have any particular package(s) you would like to see/test?
>>>> Please do let us know.
>>>
>>> yes!
>>> thanks.
>>> i'd like to nvidia-256.35 packages which would be useful for most users
>>> and would be a good test bed too. ie.:
>>> - kmod-nvidia
>>> - nvidia-x11-drv
>>> and may be like in rpmfuision
>>> - nvidia-settings
>>> - nvidia-xconfig
>>
>> I started work a while ago on porting the nvidia packages to beta1, so
>> yes those packages will definitely be top of my todo list.
>>
>> I believe the reason rpmfusion started building nvidia-settings and
>> nvidia-xconfig from source was related to selinux execstack denials. On
>> Fedora 12, allow_execstack was changed to off, and removing the
>> execution stack requirement doesn't work on 32-bit binaries so
>> rebuilding from source was their solution.
>>
>> However, rhel6beta1 still had allow_execstack -->  on by default. I've
>> not checked beta2 yet so perhaps someone would be kind enough to do that
>> please and post the results?
>>
>> getsebool -a | grep allow_exec
>>
>> Anyway, if allow_execstack remains on it's not an issue (or rather not
>> an urgent issue).
>
> we always turn off selinux by default only on production server run it:-(
> but imho these packages required because needed we've got two choices
> here elrepo or rpmfusion will package it (but unfortunately rpmfusion
> still not start packaging for el6).
> nvidia always release these 4 packages at the same time. so the question
> whether elrepo would like to ship none kmod packages or not (ok xorg
> packages almost kmod packages:-)
>

ELRepo is primarily focused on providing kmod packages, but where 
appropriate (and necessary) we will ship conventional RPM packages to 
support our kmods (for example, nvidia-x11-drv, lm_sensors etc).

So there is no issue should we decide the best thing to do is ship 
accompanying nvidia-settings and nvidia-xconfig packages built from source.

At the moment, we ship these as binaries directly from the NVIDIA 
tarball. I guess I'm looking for a reason as to why we need to change 
that and rebuild them from source? If the SELinux issue doesn't affect 
us then I see no reason to change.

>
>> Farkas - do you know if nvidia-settings and nvidia-xconfig have to be
>> rebuilt for every release so the EVR's match or if they can just be
>> built once and used with each driver release? If we do move to shipping
>> them as separate packages, would you be interested in contributing that
>> and maintaining them?
>
> one of my student already packaging these on this week, but his neither
> an rpm nor a c expert...
> the question here is the we'd like to maintain it or just contribute
> these first few packages...
>

Either way, although I suppose it's probably best I maintain them as 
they'll need to be built, signed and pushed with the other nvidia 
packages. I guess I'd just rather not add 2 additional packages to that 
churn if I don't have to. I guess this really all depends on the SELinux 
settings in the final RHEL6 release.

>>> also would be useful to test the new redhat-rpm-config's kmodtool and
>>> /usr/lib/rpm/redhat/macros's kernel_module_package macro since i
>>> _really_ like to use one and only one system wide kmodtool for all el6
>>> rpm (ie. not included in all kmod rpm).
>>>
>>> we should have to help Jon to make it much better or even send patches
>>> to them during the beta phase.
>>>
>>
>> We still plan to ship a custom kmodtool with each kmod package as that
>> will be necessary for any custom Requires and/or Provides. We are also
>
> as i always said these are only a few percent of all packages. most of
> the use the same kmodtool.
>

Yes, I understand and fully appreciate that point of view. We looked 
long and hard at kmodtool in el6 to see if we felt we could use the 
distro version by default. Our criteria was that we wanted to be 
consistent across all packages, so even if only a few packages would 
require a custom kmodtool then we felt it best that all packages do that 
to stay consistent. We apply that same philosophy elsewhere, like with 
the use of and override conf file in /etc/depmod.d/  - some kmods 
require it and on others it's arguably not needed but all have it for 
consistency.

>> currently patching kmodtool to correctly handle kmod updates via yum,
>> and have reported a bug for this against RHEL5 (which also affects RHEL6):
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=593504
>>
>> However, we do aim to stay as true as possible to the tools Red Hat
>> provides us in RHEL and we have been providing feedback to Jon Masters
>> with regard to kmodtool in the rhel6 beta.
>
> imho this is must fix before 6 GA.
>

Agreed. But as we ship our own custom kmodtool anyway, we can patch it 
if we have to - i.e, if the patch doesn't get included in RHEL6 GA.

If we don't ship a custom kmodtool, and Red Hat doesn't get it fixed, 
then we can't have updating kmod packages which makes a nonsense of kABI 
tracking packages.

>> Unfortunately, at the moment we face a somewhat wider issue concerning
>> our RHEL entitlements (which were recently withdrawn). Until we get that
>
> what was the reason?
>
>

Withdrawn was probably the wrong expression - more like our account was 
updated during a recent account review and our gifted non-commercial 
entitlements were removed. I have no idea why and we're currently 
struggling with the Red Hat Support process to get them reinstated.