[elrepo-devel] ELRepo packages for EL6

[Farkas Levente]

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:-)


> 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...

>> 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.

> 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.

> 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?


-- 
  Levente                               "Si vis pacem para bellum!"