Fedora "Jacklab" like spin

[Simon Lewis <simon.lewis@xxxxxxxxxxxxxxx>]

Hello Fernando

Thanks for the positive feedback, I'm looking forward to the final release F12, I tried the kde live beta and was surprised how fast it is. As soon as I have the final F12 installed I will try your rt kernel (2.6.31.6-rt19).

I notice that openSUSE are now shipping - as standard with 11.2- a desktop kernel (2.6.31) with full pre-emption, 1000Hz clock and PAE. (See http://www.linux-community.de/Internal/Artikel/Online-Artikel/Open-Source-Spezial/Codename-Emerald).

Where do I find the open build servers in Fedora / RPMFusion? By open build (with openSUSE) you can create one or more projects on openSUSE's server and the server is used to compile the sources based on your configuration settings. Whilst the input of the data and the configuration of the project takes time their seems to be an advantage in that the different architectures can be compiled in one run.

Given that each each distribution suffers for the lack of packages any method to improve efficiency must surely be considered. It's probably just another Utopia but has RPMFusion and Packman considered combining resources for example?

Regards, Simon


Am 10.11.2009 21:17, schrieb Fernando Lopez-Lezcano:

On Tue, 2009-11-10 at 20:05 +0100, Simon Lewis wrote:
  

Hello Fernando,
Apologies, I have seemed to stepped on a few toes here...
    

Sorry if I gave that impression, that's not what I felt. 

  

 Unfortunately for best operation of my laptop I need a the kernel
    

2.6.30.x
      

The latest rt patches are for 2.6.31 and I'm following that new set of
patches with internal builds. So far so good (just today 2.6.31.6-rt19
came out). For running 2.6.31.x on < fc12 you need to disable modeset as
the userland programs are too old (ie: "nomodeset" in the kernel boot
line) and that has delayed me putting out a version for testing. 

I tried a patch to disable that internally in the kernel and was not
successful (I can't really automatically add nomodeset to the grub boot
line because then normal fedora kernels will pick that up afterwards and
you don't want that happening). 
  

You are right nothing is easy, on the other hand given that most of
(if not all??) the developers supplying patches to the real-time
branch of the Linux kernel are Red-Hat employees. At least that's what
the press says - I thought Fedora would have the best chance of
maintaining an up to date rt kernel in their repo.
    

That would have been my guess as well. But the feedback I got from them
was not like that. Hopefully that will change over time...

  

As to packaging, it would be a great step forward if fedora /
rpmfusion were to have an open-build service like openSUSE. The
projects still have to be entered into build service but the time
compiling the different architecture / distribution versions is
reduced by build servers.
    

Both projects have "open" build servers. I don't know if the definition
of "open" would match yours, but you can become a contributor and
packager in both of them. I don't know how the openSUSE servers work. 

Best.
-- Fernando


  

Am 10.11.2009 02:51, schrieb Fernando Lopez-Lezcano: 
    

On Sun, 2009-11-08 at 11:08 +0100, Simon Lewis wrote:
  
      

Hello Orcan

Assuming that the user does and will install packages from all 3 repos
(Fedora, RPMFusion and PlanetCCRMA) then there are in fact only 2
differences between the standard fedora spin and a "studio" type spin:

(1) A kernel with enhanced pre-emption (the so called "real-time"
kernel - although this name is misleading as RT-PRIO settings can be
used effectively with the standard kernel)

(2) The automatic configuration of the RT-PRIO settings and assigning
the users to the group that has real-time priority.
    
        

Both currently available from Planet CCRMA. Rt kernels are available and
the rtirq package in conjunction with a more modern jack server than in
Fedora (with the proper priority and open rt permissions for everybody)
make both work out of the Planet CCRMA box. 

  
      

With regards to (1) the kernel with enhanced pre-emption should always
be available in the standard Fedora repository.
    
        

Yes, that would be a must for serious audio work. 

  
      

Indeed the standard and enhanced pre-emption kernels should always
have the same version number to maintain compatibility with the
graphic drivers etc.. 
    
        

That is a noble goal but it would be actually impossible to accomplish
in the real world unless a lot of manpower were to be dedicated to that.
Just as an example: there is _no_ rt patch available for the 2.6.30.x
kernel series - so it would be impossible to create an rt kernel that
matches the current fc11 kernel. Of course it would be possible to
rebase the patch but who would do it? If that were "easy" it would have
happened already. 

  
      

It would be very little additional work for the kernel compilers to
generate the kernel with pre-emption at the same time as the standard
kernel (This is standard policy at openSUSE -since 10.3 - and Ubuntu -
since 8.10).
    
        

That is not what the kernel maintainers at Fedora have said in the past.
Last time I tried to push for this they just said they don't have the
resources to do it (and presumable no interest as well). They definitely
do not want to have two kernels in Fedora. 

As a long time packager I can say that hardly ever I find something that
means "very little additional work". _Especially_ when packaging
kernels :-) You are welcome to prove me wrong by packaging them :-)

  
      

Regarding (2) it would be nice to have an administrator's tool to do
this manually as well.

I would prefer to see as many packages as possible in the Fedora and
RPMFusion repos as both these repos are subject to "rolling updates".
That is too say the packages are always kept upto date (which is one
reason why I like Fedora). The PlanetCCRMA repos are not subject to
rolling updates.
    
        

Hmmm, I upgrade packages as soon as I can. Usually that means faster
than Fedora (generally). Maybe I misunderstand what rolling update
means?

-- Fernando


  
      

As to the work load: (1) and (2) above apply to the standard fedora
distribution. The packages with tricky licensing issues to RPMFusion
or PlanetCCRMA or Livna

Regards, Simon



Am 08.11.2009 04:23, schrieb Orcan Ogetbil: 
    
        

On Sat, Oct 24, 2009 at 10:34 AM, Simon Lewis wrote:
  
      
          

Hello

Please advise if a multimedia spin for Fedora 11 is available (or for Fedora
12 planned)?

The standard Fedora 11 installation does not by default set the RT-PRIO for
jackuser or pulse audio etc., etc. Neither does the standard Fedora 11
installation automatically assign all users to the jackusers group.

For the multimedia spin to be successful these and the other necessary
configuration settings must be taken care of in the background.
Alternatively an "multimedia administration tool" for easy configuration of
the pam/usergroup settings in an RT-enviroment should be written.

Further, the standard-Kernel and RT-Kernel with same version number should
be available form the standard Fedora repository. This practice of having
the same version number for all kernel types makes it very easy for graphic
driver support etc., and means that Fedora can be booted with either kernel
type for testing purposes.


Regards, Simon.


    
        
            

Hi. Yes there was an idea but I don't think we have enough people to
generate and maintain a spin.

Moreover I am not sure where the spin should originate: Fedora,
RPMFusion or PlanetCCRMA?
The latter two has nice packages that we would like the have in the
spin, but we can't allow some (if not all) of these packages if the
spin is Fedora based.

We need ideas, manpower, time etc...

Orcan
      
          

_______________________________________________
Fedora-music-list mailing list
Fedora-music-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-music-list