From oget.fedora at gmail.com Sun Nov 8 03:23:29 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 7 Nov 2009 22:23:29 -0500 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <4AE31E84.4030407@slnet-online.de> References: <4AE31E84.4030407@slnet-online.de> Message-ID: 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 From simon.lewis at slnet-online.de Sun Nov 8 10:08:16 2009 From: simon.lewis at slnet-online.de (Simon Lewis) Date: Sun, 08 Nov 2009 11:08:16 +0100 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: References: <4AE31E84.4030407@slnet-online.de> Message-ID: <4AF69890.6020102@slnet-online.de> 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. With regards to (1) the kernel with enhanced pre-emption should always be available in the standard Fedora repository. Indeed the standard and enhanced pre-emption kernels should always have the same version number to maintain compatibility with the graphic drivers etc.. 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). 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. 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtimms at iinet.net.au Sun Nov 8 12:56:10 2009 From: dtimms at iinet.net.au (David Timms) Date: Sun, 08 Nov 2009 23:56:10 +1100 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <4AF69890.6020102@slnet-online.de> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> Message-ID: <4AF6BFEA.7030404@iinet.net.au> On 11/08/2009 09:08 PM, Simon Lewis wrote: > 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: Wait, firstly the spin couldn't be hosted at Fedora if it came with rpmfusion (or ccrma) repo enabled or with items that are not in Fedora (ie in rpmfusion or ccrma). > I would prefer to see as many packages as possible in the Fedora and > RPMFusion repos Sounds like we have a volunteer for continuing the effort to tidy up ccrma packages to fit with fedora, or failing that rpm fusion. The packages still need third party licensing examination, review requests, and resolving problems. We have a list, and Orcan and myself eg picked up a few, but there is a non-trivial process to be followed; manpower is welcome... Actually, isn't a spin really a live cd ? Would having the low level capability active, and apps installed provide anything like a realistic scenario for budding musicians, when apps need to be loaded from a livecd image ? It would also be unclear how many useful things we could fit in a CD size image (ie by expelling games|graphics|internet (most)|office) ? Cheers, DaveT. From nando at ccrma.Stanford.EDU Tue Nov 10 01:51:32 2009 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 10 Nov 2009 01:51:32 +0000 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <4AF69890.6020102@slnet-online.de> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> Message-ID: <1257817892.8625.174.camel@localhost.localdomain> 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 From simon.lewis at slnet-online.de Tue Nov 10 19:05:20 2009 From: simon.lewis at slnet-online.de (Simon Lewis) Date: Tue, 10 Nov 2009 20:05:20 +0100 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <1257817892.8625.174.camel@localhost.localdomain> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> <1257817892.8625.174.camel@localhost.localdomain> Message-ID: <4AF9B970.6000804@slnet-online.de> Hello Fernando, Apologies, I have seemed to stepped on a few toes here... Unfortunately for best operation of my laptop I need a the kernel >2.6.30.x 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. 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. Regards, Simon 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 >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nando at ccrma.Stanford.EDU Tue Nov 10 20:17:10 2009 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 10 Nov 2009 12:17:10 -0800 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <4AF9B970.6000804@slnet-online.de> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> <1257817892.8625.174.camel@localhost.localdomain> <4AF9B970.6000804@slnet-online.de> Message-ID: <1257884230.16325.67.camel@localhost.localdomain> 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 > > > > > > > > > > > From simon.lewis at slnet-online.de Thu Nov 12 17:57:57 2009 From: simon.lewis at slnet-online.de (Simon Lewis) Date: Thu, 12 Nov 2009 18:57:57 +0100 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <1257884230.16325.67.camel@localhost.localdomain> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> <1257817892.8625.174.camel@localhost.localdomain> <4AF9B970.6000804@slnet-online.de> <1257884230.16325.67.camel@localhost.localdomain> Message-ID: <4AFC4CA5.8030502@slnet-online.de> 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 >>>>> >>>>> >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nando at ccrma.Stanford.EDU Thu Nov 12 18:19:29 2009 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Thu, 12 Nov 2009 10:19:29 -0800 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <4AFC4CA5.8030502@slnet-online.de> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> <1257817892.8625.174.camel@localhost.localdomain> <4AF9B970.6000804@slnet-online.de> <1257884230.16325.67.camel@localhost.localdomain> <4AFC4CA5.8030502@slnet-online.de> Message-ID: <1258049969.4976.10.camel@localhost.localdomain> On Thu, 2009-11-12 at 18:57 +0100, Simon Lewis wrote: > 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). It will not be available immediately, there will be an announcement in the Planet CCRMA list when stuff in the fc12 branch is testable (it takes me a while to get up to speed after a new release, how long it takes depends on how busy I am and any roadblocks and surprises I get when building on the new release). > > 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. In the case of Fedora you have to become a contributor: http://fedoraproject.org/wiki/Join and more specifically: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers I presume the process is similar on RPMFusion. > Given that each each distribution suffers for the lack of packages any > method to improve efficiency must surely be considered. There is a tradeoff between efficiency and security. You don't automatically become a contributor and are able to build and release packages, basically you have to earn trust (others have to review your package before you can even think on building it, etc, etc). -- Fernando > 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. From dtimms at iinet.net.au Sat Nov 14 00:15:23 2009 From: dtimms at iinet.net.au (David Timms) Date: Sat, 14 Nov 2009 11:15:23 +1100 Subject: [Fedora-music-list] Fedora "Jacklab" like spin In-Reply-To: <1258049969.4976.10.camel@localhost.localdomain> References: <4AE31E84.4030407@slnet-online.de> <4AF69890.6020102@slnet-online.de> <1257817892.8625.174.camel@localhost.localdomain> <4AF9B970.6000804@slnet-online.de> <1257884230.16325.67.camel@localhost.localdomain> <4AFC4CA5.8030502@slnet-online.de> <1258049969.4976.10.camel@localhost.localdomain> Message-ID: <4AFDF69B.6080105@iinet.net.au> On 11/13/2009 05:19 AM, Fernando Lopez-Lezcano wrote: >> 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. If you mean rpm .spec files then yes it's similar. However, you can not be any random hacker/cracker of the street ;-) You create a .spec for the thing you want to package, and submit a review request. In time, one or more reviewers help you to knock the spec into a form where it meets the fedora / rpm fusion packaging guidelines. At this point, they also request that you perform pre-reviews of other packager's efforts. This is to show that you understand the process and guidelines (in your case, consider some other music packages - ie similar interest). At this stage an overseeing sponsor takes a look at your package Review request and decides if you have learnt enough to be accepted as a packager. It isn't that hard; but it is a little more difficult that extract, config, make, make install. The final result must: work on multiple architectures, be able to build from source, and fit with packaging guidelines which aim to stop packages stepping on each other's toes. >> 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. Yes, Fedora and RPM Fusion build requests do builds for multiple supported arch (i686, x86_64, ppc). There are other build servers for less commmon architectures like s390x and arm. > In the case of Fedora you have to become a contributor: > > http://fedoraproject.org/wiki/Join > and more specifically: > http://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > I presume the process is similar on RPMFusion. In fact, once you have become a packager for Fedora, you need to create yourself a fas account in RPM Fusion, then submit your Review Request, mentioning that you are already a Fedora packager. Please query in your Review Request, and on an appropriate list when you need help. You might like to review both bugzilla.redhat.com and bugzilla.rpmfusion.org searching for music related packages, that you might be able to help review ... DaveT (now I've got GUI on an F12 rc install, I might have a chance at getting audacity to build and work out what's going wrong) ;-0 From mschwendt at gmail.com Wed Nov 18 15:32:56 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 18 Nov 2009 16:32:56 +0100 Subject: [Fedora-music-list] Tester needed for Audacious Message-ID: <20091118163256.3c0b93a5@gmail.com> I'm in search for somebody who can give me feedback about whether the following builds of the audacious-plugins package succeed or fail at playing Musepack (.mpc) audio files: Fedora 12: audacious-plugins-2.1-18.fc12 http://koji.fedoraproject.org/koji/buildinfo?buildID=141715 Fedora 11: audacious-plugins-1.5.1-18.fc11 http://koji.fedoraproject.org/koji/buildinfo?buildID=141710 Fedora 10: audacious-plugins-1.5.1-18.fc10 http://koji.fedoraproject.org/koji/buildinfo?buildID=141711 In particular, I'm interested in tests on x86_64, since playback works fine for me on i686. If the plugin fails, please start "audacious" within a terminal and send me the output it printed during the test. If you have questions about how to download/install above builds, feel free to reply and ask. From mschwendt at gmail.com Fri Nov 20 10:54:24 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 20 Nov 2009 11:54:24 +0100 Subject: [Fedora-music-list] libmpcdec vs. Musepack SV8 Message-ID: <20091120115424.227c78cf@faldor.intranet> http://www.musepack.net/index.php?pg=src http://files.musepack.net/source/musepack_src_r435.tar.gz It seems we only have the old libmpcdec 1.2.6 in Fedora, which can decode SV7 but not SV8. Is the new set of libs and tools (from March 2009) hidden somewhere? Or are there new legal problems? From dtimms at iinet.net.au Fri Nov 20 23:38:12 2009 From: dtimms at iinet.net.au (David Timms) Date: Sat, 21 Nov 2009 10:38:12 +1100 Subject: [Fedora-music-list] Tester needed for Audacious In-Reply-To: <20091118163256.3c0b93a5@gmail.com> References: <20091118163256.3c0b93a5@gmail.com> Message-ID: <4B072864.90402@iinet.net.au> On 11/19/2009 02:32 AM, Michael Schwendt wrote: > I'm in search for somebody who can give me feedback about whether the > following builds of the audacious-plugins package succeed or fail > at playing Musepack (.mpc) audio files: How can I get/make a mpc file to test with ? From mschwendt at gmail.com Sat Nov 21 09:52:44 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 21 Nov 2009 10:52:44 +0100 Subject: [Fedora-music-list] Tester needed for Audacious In-Reply-To: <4B072864.90402@iinet.net.au> References: <20091118163256.3c0b93a5@gmail.com> <4B072864.90402@iinet.net.au> Message-ID: <20091121105244.2e81cf9e@faldor.intranet> On Sat, 21 Nov 2009 10:38:12 +1100, David wrote: > > I'm in search for somebody who can give me feedback about whether the > > following builds of the audacious-plugins package succeed or fail > > at playing Musepack (.mpc) audio files: > > How can I get/make a mpc file to test with ? Hmmm, very good question. There used to be an encoder, but I couldn't find it with various Yum queries, and the Musepack SV8 upgrade is not available in Fedora [yet]: So, here's a review request for "mppenc": https://bugzilla.redhat.com/539837 From oget.fedora at gmail.com Sat Nov 21 10:20:29 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 21 Nov 2009 05:20:29 -0500 Subject: [Fedora-music-list] Tester needed for Audacious In-Reply-To: <20091118163256.3c0b93a5@gmail.com> References: <20091118163256.3c0b93a5@gmail.com> Message-ID: On Wed, Nov 18, 2009 at 10:32 AM, Michael Schwendt wrote: > I'm in search for somebody who can give me feedback about whether the > following builds of the ?audacious-plugins ?package succeed or fail > at playing Musepack (.mpc) audio files: > > ?Fedora 12: audacious-plugins-2.1-18.fc12 > ?http://koji.fedoraproject.org/koji/buildinfo?buildID=141715 > > ?Fedora 11: audacious-plugins-1.5.1-18.fc11 > ?http://koji.fedoraproject.org/koji/buildinfo?buildID=141710 > > ?Fedora 10: audacious-plugins-1.5.1-18.fc10 > ?http://koji.fedoraproject.org/koji/buildinfo?buildID=141711 > > In particular, I'm interested in tests on x86_64, since playback > works fine for me on i686. If the plugin fails, please start "audacious" > within a terminal and send me the output it printed during the test. > > If you have questions about how to download/install above builds, > feel free to reply and ask. > My tests, with a few mpc files that I have, gave positive results on F-12 x86_64. No issues. You can push them to testing if you have not done so already. Orcan From dtimms at iinet.net.au Sun Nov 22 05:16:49 2009 From: dtimms at iinet.net.au (David Timms) Date: Sun, 22 Nov 2009 16:16:49 +1100 Subject: [Fedora-music-list] Tester needed for Audacious In-Reply-To: References: <20091118163256.3c0b93a5@gmail.com> Message-ID: <4B08C941.3060104@iinet.net.au> On 11/21/2009 09:20 PM, Orcan Ogetbil wrote: > On Wed, Nov 18, 2009 at 10:32 AM, Michael Schwendt wrote: >> I'm in search for somebody who can give me feedback about whether the >> following builds of the ? audacious-plugins ? package succeed or fail >> at playing Musepack (.mpc) audio files: >> >> ? Fedora 12: audacious-plugins-2.1-18.fc12 >> ? http://koji.fedoraproject.org/koji/buildinfo?buildID=141715 Works fine for me (i686). >> ? Fedora 10: audacious-plugins-1.5.1-18.fc10 >> ? http://koji.fedoraproject.org/koji/buildinfo?buildID=141711 Also works fine (x86_64). The mpc file I tested with was created with mppenc, with no parameters other than the source wav name. Perhaps the issue is encoding/compression parameter specific, or due to the particular compressor that made it ? From mschwendt at gmail.com Sun Nov 22 11:39:37 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 22 Nov 2009 12:39:37 +0100 Subject: [Fedora-music-list] Tester needed for Audacious In-Reply-To: References: <20091118163256.3c0b93a5@gmail.com> Message-ID: <20091122123937.1d93a464@faldor.intranet> On Sat, 21 Nov 2009 05:20:29 -0500, Orcan wrote: > My tests, with a few mpc files that I have, gave positive results on > F-12 x86_64. No issues. Thanks for the test. Basically, the worst that could have happened is that the plugin failed to play anything on x86_64 _actually_ while it simply refuses to fail on i686. ;) > You can push them to testing if you have not > done so already. Yes, this has been done meanwhile including a few more patches for unrelated issues. From mschwendt at gmail.com Sun Nov 22 11:41:21 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 22 Nov 2009 12:41:21 +0100 Subject: [Fedora-music-list] Tester needed for Audacious In-Reply-To: <4B08C941.3060104@iinet.net.au> References: <20091118163256.3c0b93a5@gmail.com> <4B08C941.3060104@iinet.net.au> Message-ID: <20091122124121.3a4f8492@faldor.intranet> On Sun, 22 Nov 2009 16:16:49 +1100, David wrote: > >> ? Fedora 12: audacious-plugins-2.1-18.fc12 > >> ? http://koji.fedoraproject.org/koji/buildinfo?buildID=141715 > Works fine for me (i686). Great. Thanks for the testing. > >> ? Fedora 10: audacious-plugins-1.5.1-18.fc10 > >> ? http://koji.fedoraproject.org/koji/buildinfo?buildID=141711 > Also works fine (x86_64). Hah, and another success report for x86_64. That's good. > The mpc file I tested with was created with mppenc, with no parameters > other than the source wav name. > > Perhaps the issue is encoding/compression parameter specific, or due to > the particular compressor that made it ? Yes, SV7 (StreamVersion7) is the only encoding that's currently understood by libmpcdec in Fedora. The issue with the plugin was that due to old cruft in its implementation (an extra decoding thread) it messed up the playback with symptoms like playing at fast-forward speed with heavy interruptions. That was reproducible on i686, too. The fix -- and the musepack plugin is not the only plugin that required such a fix -- works fine on i686, but the one person, who had pointed out problems, can't get it to play any files at all anymore. He doesn't get any debug output either. Not even the plugin's "play" function is called according to the missing debug output, which suggests that either the files (said to be SV7) are not recognised by the decoding library or there is another problem/side-effect on x86_64.