[12:46] ScottL: i think i cant make it to the meeting today [12:47] ScottL: i have to go to the ariport and i am not sure if i get home in time [12:53] jussi: are you there? [12:53] I am thinking on a implementation of the UBS controls [12:55] what do you think if the controls utility, could download from a server a text file with the list of PPA we determine safe for ubuntustudio [12:55] this way we wouldnt need to upgrade the package each time some PPA changes, or something new is needed to be added [12:56] if so, where can i put that file? some safe place, also it sgould be GPG signed, but i dont know how, maype gziped or something [13:13] rlameiro, i don't think we are ready for a meeting today, i know i'm not [13:13] ok [13:14] ScottL: what do you thing about the file download? [13:53] rlameiro, hmm, i'm not sure, i'd have to think about it [13:53] my first thought is that i would rather we test the ppa ourselves and then copy the build into our own ppa [13:54] this keeps a single ppa for user's to worry about [13:54] but, this does not prevent us from fixing the rtprio and memlock settings, which is actually pretty important [13:55] ScottL: well, but the backpots need to have its own ppa [13:55] i need to look into the rtprio stuff [13:56] it needs to be added to the audio.d/config isnt it [13:56] rlameiro, true, but we could include one other for "extended" universe ppa (or whatever name we come up with) [13:56] ok [13:56] like enable backports ppa [13:56] and another with enable ubuntustudio universe team ppa [13:56] or something [13:57] https://wiki.ubuntu.com/UbuntuStudio/Meetings/2010May16 [13:57] /etc/security/limits.d/audio.conf [13:57] the link provides alink to mailing list discribing it, but you seee the file also below my link [13:57] yes that, misspelled it [13:58] i just dont get that stuff of not adding the user to the @audio group when using PA [13:58] i have misgivings about enabling ppa's that we do not have control over, we cannot guarentee their quality and we would receive the bugs for them [13:59] ScottL: me too [13:59] I was thinking on separate ppa, just that [14:00] but all controlled by the team, also the list would need to be approved by the team, but maybe its better to have just one ppa with everything [14:01] the way i understood dtchen's explanation, is that the active user (the one at the keyboard) has rights to the /dev/snd/* which means you have access to the @audio group [14:01] i wanted to put the kernel in a diferent one, because, that way, we could warn users about the rt kernel implications [14:01] even with jack? [14:01] you are not explicitly in the group but because you are the person logged on you access to that groups rights [14:02] humm [14:02] ok [14:02] that's a good idea about the kernel [14:02] ScottL: http://kxstudio.sourceforge.net/index.php?option=com_content&view=article&id=44&Itemid=12 [14:03] ScottL: the idea was like this, the user selects the checkbox for the kernels PPA and a Warnig box appears [14:03] according to dtchen, this should work, even with jack...of course there may be unforseen situations [14:03] saying that you may have problems with the propietary kernels etc [14:03] the things abogani explained on the mailing list [14:03] proprietary drivers? instead of proprietary kernels? [14:04] ScottL: when you instal the rt kernel, ussually users have some problems with the nvida and ATI propietary drivers [14:04] this is a defense for us, or elese we would be swamped with bugs and complains [14:05] i meant that you said "saying that you may have problems with the propietary kernels etc" but i realize you meant drivers not kernels [14:05] if they want rt kernels, they should know thew caveeats [14:05] exactly [14:05] oops, sorry fail [14:05] :D [14:05] lol [14:06] i'm hoping this is transitory...if preempt gets in archives and can be shipped by default, many may not want to switch because performance is acceptable [14:06] transitory = people wanting -rt kernels [14:06] yeap, but there are still situations whwere rt kernels is better, for instance with laptops [14:07] my understanding is that we cannot make an -rt kernel without Igno's patch, and that leaves us in a difficult position sometimes [14:07] as the mobile processor have some weard differences, with the rt you can push it to the limit [14:07] ScottL: no, if we tell the user :D [14:08] we are not the devs, we just try to get together the best software [14:08] we are not kernel devs [14:08] rlameiro, i fear that most users think we work in a fantasy land and we have all the knowledge, resources, and time to make things "right" and that somehow we just choose to screw things up for select peoples [14:08] the problem is that most people think that ubuntustudio makes its own kernel, and all software [14:08] precisely [14:09] "omnipotent" gods thats fail [14:09] so, ubuntustudio controls could be a way to WAR users about the caveats [14:09] and also ask for help [14:09] it can be naggy, but yes it is needed [14:10] a dialogue box would be nice to tell them of the dangers and a link to an informative website would be a really good thing IMO [14:10] precisely my idea [14:10] with a BIG warning triangle [14:10] english is my native tongue and my last sentence was pretty horrible :P [14:10] we also should push translation [14:11] maybe I should have an editor and a translator :P [14:11] lol [14:11] i got you :D [14:11] that's why i worry about abogani and the way he gets down on himself about his english [14:12] i really do think he types it better than a lot of native english speakers [14:13] ScottL: that is normal with us, because our native language isn't english, but we do spend most of our time reading stuff in english [14:13] once we get an ISO build that works i should be updating the seeds to include the new lv2 stuff and hopefully moderating the menu for them as well [14:13] so sometimes qe feel that we should do better at it [14:13] even if something is spoken (or written) not quite correctly but the intent is understood, then that is a win [14:14] because sometimes even for those born in US and speak english natively, it is difficult to understand some spoken dialogue because of slang and poor word choices [14:14] it's not what you would call "proper english" but it gets understood the same more or less [14:15] yea, true, sometimes i cant get some english expressions ou there :D [14:16] oh, and when we get an ISO build that installs I really want to test JACK/Pulse Audio together and see what's different [14:16] ScottL: do you know another ubuntu channel for developres, besides #ubuntu-dev? [14:16] i do not...i wasn't even directly aware of #ubuntu-dev until now [14:16] ScottL: about that,, http://kxstudio.sourceforge.net/index.php?option=com_content&view=article&id=44&Itemid=12 [14:17] i think we could implement it on controls [14:17] as enable it or disable it [14:17] which part? [14:17] also warning that when jack is stoped pulse crash :D [14:17] the pulse/jack [14:18] you mean the bridge? [14:18] so you can get pulse audio into jack and vice versa [14:18] yeap [14:18] i agree, but probably not this cycle [14:19] i am expected to have some troubles still with maverick in terms of getting jack and pulse enabled and working in a stable manner vai dbus [14:19] maybe [14:19] not that i have great or expansive knowledge of the subject [14:20] but when we change infrastructure like this it seems to have "unforeseen consequences" which take a cycle to rectify [14:20] it depends on how can i make it or not [14:20] i have some spare time now [14:20] i'm not talking about -controls [14:20] i am starting to reading stuff about python-apt etc [14:20] i need to make a mock-up and implement it [14:21] but first can we fix the rtprio and memlock situation, that is clearly defined and pretty critical [14:21] also i will meet in person RNCBC in 15 days so i can ask him directly about rtirq [14:22] hey, that's pretty cool! [14:22] ScottL: AFAIK the issue is easy to fix, just changing the file path in the python script [14:22] that is the first thing i will do [14:22] that and remove nice [14:23] rlameiro, i would even suggest that we fix that first, test it, and then push the changes now to improve usability [14:23] ScottL: should i develop it on the alpha? [14:23] and then worry about other improvements [14:23] ScottL: for lucid? [14:23] you could develop on lucid i think without any problems [14:24] i dont know if i can [14:24] you don't know if you can update -controls on lucid? [14:24] the problems with rtprio came because the change was made between karmic and lucid [14:24] so never was detected fixed in time [14:25] if you can update -controls on a lucid install, it should be able to be merged into the code for maverick and then released [14:25] but, of course it can be developd in lucid, but needs testing on MM [14:25] yeap [14:25] then an SRU can be filed to get it released into lucid still during maverick's development [14:25] thats tha [14:26] thats it, so we can push it to lucid also :D [14:26] thats what i wanted to know :D [14:26] oh good :) [14:27] hopefully you can make the rtprio, memlock, and nice changes, they get reviewed and testing in lucid, and then an MM ISO is available to test as well [14:28] then we can merge the code for MM [14:28] afk a few minutes [14:28] ok [14:58] ScottL: ok, i just removed nice from UScontrols [14:58] rlameiro, sorry had to finish a blog post before the family woke up http://dullass.blogspot.com/ [14:59] good :) [14:59] i changed the file were writ the memlock, but there is already info on mine [15:00] rlameiro, did you just remove the code or did you comment them out? i think i would advocate commenting them out for the time being [15:00] the instllation process of jack already does some stuff, so i need to make something to check for the actuall state of the file, or it will addin one more line [15:00] i removed it [15:00] yes, that is true [15:00] but its not important [15:00] its only mu branch [15:00] we have the old code still so it's not that big of a concern [15:00] after i make a diff and commnet out the original [15:01] rlameiro, it's time for me to go, i have to wake up son and get him ready for us to go out into town [15:01] also, there is a commented line with a nice setting /etc/security/limits.d/audio.conf [15:02] go go [15:02] rlameiro, ciao, i always enjoy talking with you [15:02] have a good time [15:02] mee to :D [20:13] hi again [20:14] ScottL: i just reconfigured jack, using $dpkg-reconfigure -p high jackd and it added memlock unlimited, and rtprio 99 [20:14] both to @audio [20:14] so, i dont know, why do need ubuntustudio controls for the moment... [20:15] besides enabling firewire [20:16] crimsun_: I would love if you could clarify some things avout the audio setup at the moment [20:17] as i want to push ASAP a modified version of ubuntustudio controls for the 10.04.1