|
I would like to second the notion that a real time kernel would be the best option for this distro. I hate to be a pessimist, but I don't see the point of making a music spin if it is going to have the same kernel as the the standard fedora distro. Anyone can add packages, but a working rt kernel is special. Also, if the real time kernel gets added, I think it may receive more attention and maybe get some nice improvements. If we have to call it a remix and not spin, that is not important to me. What is important is how useful it is to musicians and musicians do not like latency. I understand that the kernel patch can be installed quite easily and this is just my opinion. Please feel free to object to me or to correct me. :) > From: music-request@xxxxxxxxxxxxxxxxxxxxxxx > Subject: music Digest, Vol 44, Issue 13 > To: music@xxxxxxxxxxxxxxxxxxxxxxx > Date: Thu, 22 Jul 2010 06:20:00 +0000 > > Send music mailing list submissions to > music@xxxxxxxxxxxxxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > https://admin.fedoraproject.org/mailman/listinfo/music > or, via email, send a message with subject or body 'help' to > music-request@xxxxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > music-owner@xxxxxxxxxxxxxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of music digest..." > > > Today's Topics: > > 1. Re: Music spin development - are you ready to get involved ? > (Fernando Lopez-Lezcano) > 2. Re: [PlanetCCRMA] Music Spin (Fernando Lopez-Lezcano) > 3. Re: [PlanetCCRMA] Music Spin (Bernardo Barros) > 4. Re: Music spin development - are you ready to get involved ? > (Bernardo Barros) > 5. Re: Music spin development - are you ready to get involved ? > (Christopher Antila) > 6. Re: [PlanetCCRMA] Music Spin (Fernando Lopez-Lezcano) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Jul 2010 10:13:14 -0700 > From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> > Subject: Re: [Fedora-music-list] Music spin development - are you > ready to get involved ? > To: David Timms <dtimms@xxxxxxxxxxxx> > Cc: music@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <1279732394.22338.2.camel@xxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="UTF-8" > > On Thu, 2010-07-22 at 01:19 +1000, David Timms wrote: > > Hi all, > > > > I have begun a wiki page to help track our goals for an audio creation > > Fedora spin: > > https://fedoraproject.org/wiki/AudioCreationSpinDevelopment > > , also available from the links at the bottom of the SIG page: > > https://fedoraproject.org/wiki/Audio_Creation > > > > If you want to be involved, please make sure you have a Fedora wiki > > account (fas), and list yourself in the collaborators section. > > > > You'll probably find many areas of the page need flashing out or fixing > > up; please do so, but also consider the limited time frame before the > > next Fedora release. > > > > A name like "Open Music Workstation" ... or "Fedora Jam", but you can > > think of better, I'm sure... > > > > Meanwhile, as we are trying to show off collaboration, is there any > > software that allows distant users to jam / create music over the > > internet ? This would be something really quite unique, compared to > > other spins. > > Jacktrip, already part of Planet CCRMA, see: > https://ccrma.stanford.edu/groups/soundwire/ > > and in particular: > http://code.google.com/p/jacktrip/ > > -- Fernando > > > > > ------------------------------ > > Message: 2 > Date: Wed, 21 Jul 2010 10:21:55 -0700 > From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> > Subject: Re: [PlanetCCRMA] Music Spin > To: David Sommerseth <davids@xxxxxxxxxx> > Cc: music@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <1279732915.22338.11.camel@xxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 19/07/10 18:57, Fernando Lopez-Lezcano wrote: > > > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote: > > >> > For this low-level task some engineering would be required? I'm not > > >> > this kind of guy who know much about tasks scheduling and priorities > > >> > (kernel level) but some people told me that real-time kernels patches > > >> > could slow down Fedora and I should not use it. > > > > > > Did those people by any chance provide you with _numbers_ that tell you > > > exactly what part of the kernel is impacted and by how much? (and, who > > > are they?) My guess is probably not. > > > > > > Yes, perhaps the rt patches could affect performance. Maybe. In some > > > subsystems (disk i/o, network come to mind). Maybe by a few %, in some > > > specific situations. I don't think the impact will be something you will > > > notice unless you measure it. > > > > To put things a bit straight. Yes, RT kernel will affect performance. > > Point. > > Agreed (for the reasons you explain below). > > I'd like to add that in the context of real-time performance for audio, > the lack of an RT kernel will also affect performance for the worse. So, > it depends on your goals. In the context of this list (music) Bernardo > comments he got the recommendation to not run RT kernels for performance > reasons ("some people told me that real-time kernels patches could slow > down Fedora and I should not use it"). > > If you are running a server, don't (unless, of course, you print money > by running thousands of trades a minute and you need millisecond > scheduling for that - that is why we have the rt patches after all :-). > If you are running a music oriented workstation that should handle > real-time interaction, then I'd say yes, run it. > > There are no black and white rules here. If you try the Fedora kernel > and it works for you in your particular music oriented situation then > run that. > > -- Fernando > > > > Will you notice it effectively on "normal desktop tasks"? Probably not > > much, but it depends on how your system is saturated, tuned and what > > kind of loads you have running. Real Time is not Real Fast and never > > will be. A real time kernel will not give any fair scheduling to your > > system, basically. > > (depends on your definition of "fair", for the purposes of an RT kernel > it schedules processes fairly, giving the rt tasks priority as is > intended by design). > > > All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR > > scheduling, even on the lowest priority will preempt and run it first > > over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and > > SCHED_RR tasks with the highest priority will be processed before all > > other tasks, whenever they receive signals which requires these > > processes to run. This is the core nature of a real time system. > > > > So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they > > are light - you most probably will not notice anything at all. But in > > the moment you begin with heavy I/O dependent operations or other > > operations which requires processing time and the kernel have given them > > SCHED_FIFO scheduling and a rather high priority (which is not > > uncommon), it will slow down all the other running tasks. But this > > behaviour is possible to tune! > > > > So why would you want to run a real time kernel instead of a so called > > "real fast" kernel (normal kernels)? Latency determination. A real > > time kernel will strive to give you a predictable system latency, no > > matter how loaded your computer is. Which is a key-point for audio and > > video - you don't want the sound or video stream to be delayed because > > cron and updatedb wants to run. > > > > Some relevant information can be found here: > > > > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html> > > > > > > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html> > > > > > > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html> > > > > > > kind regards, > > > > David Sommerseth > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d > > mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/ > > =vj0G > > -----END PGP SIGNATURE----- > > _______________________________________________ > > music mailing list > > music@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/music > > > > > ------------------------------ > > Message: 3 > Date: Wed, 21 Jul 2010 15:18:16 -0300 > From: Bernardo Barros <bernardobarros2@xxxxxxxxx> > Subject: Re: [PlanetCCRMA] Music Spin > To: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> > Cc: music@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: > <AANLkTilHaP29jI3NnWHELlcH0rUPxzkbmBADvgq_3EkF@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset=UTF-8 > > Thank you Fernando and David, > > Yes, the person that gave me advise was not an audio oriented guy. > That?s more clear now. > > Just a newbie question here: do you have to determine what programs > will have privileges? How the system knows how to handle taks of audio > and non-audio programs at the same time? > > 2010/7/21 Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>: > > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote: > >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote: > >> >> > For this low-level task some engineering would be required? I'm not > >> >> > this kind of guy who know much about tasks scheduling and priorities > >> >> > (kernel level) but some people told me that real-time kernels patches > >> >> > could slow down Fedora and I should not use it. > >> > > >> > Did those people by any chance provide you with _numbers_ that tell you > >> > exactly what part of the kernel is impacted and by how much? (and, who > >> > are they?) My guess is probably not. > >> > > >> > Yes, perhaps the rt patches could affect performance. Maybe. In some > >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some > >> > specific situations. I don't think the impact will be something you will > >> > notice unless you measure it. > >> > >> To put things a bit straight. ?Yes, RT kernel will affect performance. > >> Point. > > > > Agreed (for the reasons you explain below). > > > > I'd like to add that in the context of real-time performance for audio, > > the lack of an RT kernel will also affect performance for the worse. So, > > it depends on your goals. In the context of this list (music) Bernardo > > comments he got the recommendation to not run RT kernels for performance > > reasons ("some people told me that real-time kernels patches could slow > > down Fedora and I should not use it"). > > > > If you are running a server, don't (unless, of course, you print money > > by running thousands of trades a minute and you need millisecond > > scheduling for that - that is why we have the rt patches after all :-). > > If you are running a music oriented workstation that should handle > > real-time interaction, then I'd say yes, run it. > > > > There are no black and white rules here. If you try the Fedora kernel > > and it works for you in your particular music oriented situation then > > run that. > > > > -- Fernando > > > > > >> Will you notice it effectively on "normal desktop tasks"? ?Probably not > >> much, but it depends on how your system is saturated, tuned and what > >> kind of loads you have running. ?Real Time is not Real Fast and never > >> will be. ?A real time kernel will not give any fair scheduling to your > >> system, basically. > > > > (depends on your definition of "fair", for the purposes of an RT kernel > > it schedules processes fairly, giving the rt tasks priority as is > > intended by design). > > > >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR > >> scheduling, even on the lowest priority will preempt and run it first > >> over, ignoring all other SCHED_OTHER (normal) processes. ?SCHED_FIFO and > >> SCHED_RR tasks with the highest priority will be processed before all > >> other tasks, whenever they receive signals which requires these > >> processes to run. ?This is the core nature of a real time system. > >> > >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they > >> are light - you most probably will not notice anything at all. ?But in > >> the moment you begin with heavy I/O dependent operations or other > >> operations which requires processing time and the kernel have given them > >> SCHED_FIFO scheduling and a rather high priority (which is not > >> uncommon), it will slow down all the other running tasks. ?But this > >> behaviour is possible to tune! > >> > >> So why would you want to run a real time kernel instead of a so called > >> "real fast" kernel (normal kernels)? ?Latency determination. ?A real > >> time kernel will strive to give you a predictable system latency, no > >> matter how loaded your computer is. ?Which is a key-point for audio and > >> video - you don't want the sound or video stream to be delayed because > >> cron and updatedb wants to run. > >> > >> Some relevant information can be found here: > >> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html> > >> > >> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html> > >> > >> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html> > >> > >> > >> kind regards, > >> > >> David Sommerseth > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.10 (GNU/Linux) > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >> > >> iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d > >> mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/ > >> =vj0G > >> -----END PGP SIGNATURE----- > >> _______________________________________________ > >> music mailing list > >> music@xxxxxxxxxxxxxxxxxxxxxxx > >> https://admin.fedoraproject.org/mailman/listinfo/music > > > > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 21 Jul 2010 15:20:50 -0300 > From: Bernardo Barros <bernardobarros2@xxxxxxxxx> > Subject: Re: [Fedora-music-list] Music spin development - are you > ready to get involved ? > To: David Timms <dtimms@xxxxxxxxxxxx> > Cc: music@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: > <AANLkTik2UTrKoyXjUv7GPmMkqg1CcCNCZGAFrmFtvt0D@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset=UTF-8 > > 2010/7/21 David Timms <dtimms@xxxxxxxxxxxx>: > > A name like "Open Music Workstation" ... or "Fedora Jam", but you can > > think of better, I'm sure... > > My suggestion is "Planet Music" Spin as an hommenage to the work of > Fernando to the Linux Audio community. > > > ------------------------------ > > Message: 5 > Date: Wed, 21 Jul 2010 20:16:20 -0400 > From: Christopher Antila <crantila@xxxxxxxxx> > Subject: Re: Music spin development - are you > ready to get involved ? > To: music@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <4C478DD4.9010509@xxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello: > > Thanks to David for getting this started for us. I was going to post a > (nearly empty) wiki page for this purpose today, but it's better that a > more experienced user does it. > > I'll be adding my comments to the wiki pages as appropriate, and I > everybody else joins in, too. > > Also, I don't want to be beating people over the head with this, but the > Docs SIG is publishing a Guide for music and audio software with Fedora > 14. We'll have to see exactly how these fit together, but remember that > the Guide will be there. > > Finally, since I'm in fairly regular contact with Docs, I'll take > responsibility for maintaining the Audio Creation <-> Docs link, if the > Spin goes ahead. First step is to ask if we can add a "beat" in the > Release Notes ("What's new in Fedora 14 for Musicians?" or something > like that). If you don't know what this is, check out the Fedora 13 > release notes... it would probably fall under chapter 7: > > http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html > > > Let's get this thing rolling! > > Christopher. > > > On 07/21/2010 11:19 AM, David Timms wrote: > > Hi all, > > > > I have begun a wiki page to help track our goals for an audio creation > > Fedora spin: > > https://fedoraproject.org/wiki/AudioCreationSpinDevelopment > > , also available from the links at the bottom of the SIG page: > > https://fedoraproject.org/wiki/Audio_Creation > > > > If you want to be involved, please make sure you have a Fedora wiki > > account (fas), and list yourself in the collaborators section. > > > > You'll probably find many areas of the page need flashing out or fixing > > up; please do so, but also consider the limited time frame before the > > next Fedora release. > > > > A name like "Open Music Workstation" ... or "Fedora Jam", but you can > > think of better, I'm sure... > > > > Meanwhile, as we are trying to show off collaboration, is there any > > software that allows distant users to jam / create music over the > > internet ? This would be something really quite unique, compared to > > other spins. > > > > Cheers, David. > > _______________________________________________ > > music mailing list > > music@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/music > > > ------------------------------ > > Message: 6 > Date: Wed, 21 Jul 2010 23:19:31 -0700 > From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> > Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin > To: Bernardo Barros <bernardobarros2@xxxxxxxxx> > Cc: music@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <1279779571.25375.245.camel@xxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2010-07-21 at 15:18 -0300, Bernardo Barros wrote: > > Thank you Fernando and David, > > > > Yes, the person that gave me advise was not an audio oriented guy. > > That?s more clear now. > > > > Just a newbie question here: do you have to determine what programs > > will have privileges? How the system knows how to handle taks of audio > > and non-audio programs at the same time? > > You don't have to worry about determining which programs will have > privileges (at least directly). > > If you run Jack with real-time scheduling (if you use Qjackctl you have > to set the "Realtime" parameter in "Setup" and the user that is running > Jack has to be allowed to use real-time scheduling), then the audio > threads within any Jack client will run with real-time scheduling > automatically. > > All other threads in all your programs will run with "normal" scheduling > and will have less priority (that includes, for example, graphic i/o > threads or file i/o threads in the Jack audio programs - those don't > have elevated priority). > > It is all designed to make sure the chances of an audio glitch happening > are as small as possible. > > -- Fernando > > > > 2010/7/21 Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>: > > > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote: > > >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote: > > >> >> > For this low-level task some engineering would be required? I'm not > > >> >> > this kind of guy who know much about tasks scheduling and priorities > > >> >> > (kernel level) but some people told me that real-time kernels patches > > >> >> > could slow down Fedora and I should not use it. > > >> > > > >> > Did those people by any chance provide you with _numbers_ that tell you > > >> > exactly what part of the kernel is impacted and by how much? (and, who > > >> > are they?) My guess is probably not. > > >> > > > >> > Yes, perhaps the rt patches could affect performance. Maybe. In some > > >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some > > >> > specific situations. I don't think the impact will be something you will > > >> > notice unless you measure it. > > >> > > >> To put things a bit straight. Yes, RT kernel will affect performance. > > >> Point. > > > > > > Agreed (for the reasons you explain below). > > > > > > I'd like to add that in the context of real-time performance for audio, > > > the lack of an RT kernel will also affect performance for the worse. So, > > > it depends on your goals. In the context of this list (music) Bernardo > > > comments he got the recommendation to not run RT kernels for performance > > > reasons ("some people told me that real-time kernels patches could slow > > > down Fedora and I should not use it"). > > > > > > If you are running a server, don't (unless, of course, you print money > > > by running thousands of trades a minute and you need millisecond > > > scheduling for that - that is why we have the rt patches after all :-). > > > If you are running a music oriented workstation that should handle > > > real-time interaction, then I'd say yes, run it. > > > > > > There are no black and white rules here. If you try the Fedora kernel > > > and it works for you in your particular music oriented situation then > > > run that. > > > > > > -- Fernando > > > > > > > > >> Will you notice it effectively on "normal desktop tasks"? Probably not > > >> much, but it depends on how your system is saturated, tuned and what > > >> kind of loads you have running. Real Time is not Real Fast and never > > >> will be. A real time kernel will not give any fair scheduling to your > > >> system, basically. > > > > > > (depends on your definition of "fair", for the purposes of an RT kernel > > > it schedules processes fairly, giving the rt tasks priority as is > > > intended by design). > > > > > >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR > > >> scheduling, even on the lowest priority will preempt and run it first > > >> over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and > > >> SCHED_RR tasks with the highest priority will be processed before all > > >> other tasks, whenever they receive signals which requires these > > >> processes to run. This is the core nature of a real time system. > > >> > > >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they > > >> are light - you most probably will not notice anything at all. But in > > >> the moment you begin with heavy I/O dependent operations or other > > >> operations which requires processing time and the kernel have given them > > >> SCHED_FIFO scheduling and a rather high priority (which is not > > >> uncommon), it will slow down all the other running tasks. But this > > >> behaviour is possible to tune! > > >> > > >> So why would you want to run a real time kernel instead of a so called > > >> "real fast" kernel (normal kernels)? Latency determination. A real > > >> time kernel will strive to give you a predictable system latency, no > > >> matter how loaded your computer is. Which is a key-point for audio and > > >> video - you don't want the sound or video stream to be delayed because > > >> cron and updatedb wants to run. > > >> > > >> Some relevant information can be found here: > > >> > > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html> > > >> > > >> > > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html> > > >> > > >> > > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html> > > >> > > >> > > >> kind regards, > > >> > > >> David Sommerseth > > >> -----BEGIN PGP SIGNATURE----- > > >> Version: GnuPG v1.4.10 (GNU/Linux) > > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > >> > > >> iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d > > >> mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/ > > >> =vj0G > > >> -----END PGP SIGNATURE----- > > >> _______________________________________________ > > >> music mailing list > > >> music@xxxxxxxxxxxxxxxxxxxxxxx > > >> https://admin.fedoraproject.org/mailman/listinfo/music > > > > > > > > > > > > > > ------------------------------ > > _______________________________________________ > music mailing list > music@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/music > > End of music Digest, Vol 44, Issue 13 > ************************************* Get a free e-mail account with Hotmail. Sign-up now. |
_______________________________________________ music mailing list music@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/music
