[09:40] * stochastic waves [10:00] Heya. [12:53] ScottL: Given the feedback, I think it's worth keeping the non-audio stuff around, all the more so since Desktop dropped GIMP, etc. [12:53] ScottL: But it would definitely be worth a renewed call for which applications are considered core applications for use for the amateur/hobbist/student/etc. user. [12:54] * persia believes there to be no suitable high-grade tools, although some that may be suitable for certain classes of production (e.g. webart). [12:58] persia, i have kinda a good news for you [12:58] Which? [12:59] http://www.omgubuntu.co.uk/2010/04/oscar-winning-video-editor-goes-open.html [12:59] it edits vido up to 2k!!!!!!! [12:59] more pro than that i difficult :D [13:00] Suitable target for maverick+1, for next April, if someone starts now. [13:00] but they are talking to open it only on the 3rd quartes [13:00] so no maverick [13:00] yeah [13:00] Oh, right. Then maverick+2 [13:01] Many times when some project is freshly open-sourced, there's a mess that needs digging regarding licensing. [13:01] well, it depends, if it is a linux version of it at launch time, well maybe it could be packaged for maverick+1 [13:01] oh, licenses.... yeah [13:01] Common issues are reliance on embedded forks of libraries, incomplate licensing adjustments, code review to ensure appropriate attributions, etc. [13:02] well, if they have all the copyright on the editor [13:02] rlameiro: Indeed. If upstream executes perfectly, and supports Ubuntu out-of-the-box, it *might* make maverick. [13:02] Err, maverick+1. [13:02] and they open it up, maybe it will be all on the same license [13:02] rlameiro: Are you sure? Do you know that no lazy coder they ever employed copied some snippet of code found online? [13:03] well, nevertheless it is a good new [13:03] persia: lol, maybe.... [13:03] but like that the review will take months [13:03] And if they release it as all the same license, are you sure they will go through and appropriately license the source files, or just give a *separate* license grant to the source-as-a-whole whlist leaving standard closed-source headers, etc. [13:03] Right. [13:04] but i think thats is waht a company does before releasing something opensource [13:04] That's why I say maverick+2, if someone starts when the source is out, or maverick+1 if someone could start now :) [13:04] Some companies do, and those should be commended. [13:04] If that happens, then someone *is* starting now, so we might hit maverick+1 [13:04] i think they will release that on a bsd like license [13:04] (the someone concerned might be staff that the company) [13:04] they want to sell plugins for it [13:05] Lots of licenses allow that. [13:05] does gpl allow that? [13:06] Depends on how the plugin interface is implemented. Sometimes. [13:06] hummmm [13:06] LGPL is more likely to allow it. [13:06] well, we need to wait [13:06] Yep. [13:06] ok abaout your idea to ask again for software to stay in, and software out of US i agree with you [13:07] we should decide what US will be aimed off [13:07] GIMP is missing from the desktop, so US can gain from it [13:07] but at the core US needs to solve basic problems [13:08] For some value of "we", I agree. [13:08] we as community, of course [13:08] for instance, it is imperative to have networking out the box [13:09] change the ART, or at least the theme [13:09] When you say "networking out of the box", what do you mean? [13:09] after indtall you have networkmanager installed [13:09] Why? [13:10] i couldnt install it from cd easily [13:10] So, what didn't the included network management tool do for you? [13:10] How didn't that work? [13:10] The idea isn't for you to tell me specifically, but for something to think about. [13:10] Network manager requires a fair bit of sporadic resources. [13:10] when i tried to use the cd as a repo, it didnt worked [13:11] It's not much under user-contrl. [13:11] could be, but the majority of the user want networking, its easiar to unistall it if you dont want [13:11] I think we're not communicating. [13:12] we?? you and me, or the community? [13:12] I agree that the majority of users want networking. I'm unsure that network-manager is the solution that best meets the needs of folk who may have realtime requirements. [13:12] You and I. [13:13] i agree, but when i work in rt intensive app, i just diconnect networking [13:13] So, for those doing audio work, or those rendering animation, etc. network-manager is a decidedly suboptimial solution to the problem. [13:13] Why? [13:13] There's lots of use cases to have working networking during a session. [13:13] yes they are [13:13] i use it [13:13] e.g. rendering to network store, shared ardour sessions, MIDI-over-ethernet, etc. [13:13] for instance using OSC needs networking [13:13] Right. [13:14] so we need networking [13:14] networking != network-manager [13:14] well, i dont think most of the people would want to mess with ifconfig and friends.... [13:14] We've historically shipped with gnome-network-admin, which doesn't run all the time, and only does stuff when the user tells it to do stuff. [13:15] If gnome-network-admin has a bug, that bug should be fixed. [13:15] yeah, never worked for me [13:15] So, figure out how it didn't work, and file some bugs. [13:15] does it support wireless? [13:15] Should do. [13:16] * rlameiro digging about gnome-network-admin [13:17] persia: for instance i never got this choice [13:17] http://library.gnome.org/users/network-admin/2.30/tool-getting-started.html.en [13:17] it was empty [13:18] File a bug. [13:18] humm [13:18] ok [13:18] I agree there should be networking out of the box. [13:18] i will need to reboot into the amd64 RC i have installed [13:18] I'm just not convinced that the solution is to install something else, rather than fixing what we have, without analysis. [13:19] It may be that network-manager is the right solution. It is not the case that someone decided to make networking not work. [13:21] networkmanager is usig 5 mb ram [13:21] and the applet 2.9 [13:21] CPU is 0 [13:21] and i am using WPA2 wireless [13:22] CPU usage for gnome-network-admin should *only* happen whilst actually configuring stuff. CPU for network-manager happens variously, as it adjusts the current connection and scans for others, etc. [13:23] humm ok [13:23] i will reboot into it and see how it goes [13:23] i will need a restricted driver for my wireless card [13:23] maybe that is the problem [13:23] i need internet to get it [13:24] Ugh. [13:24] yeah [13:24] For some drivers, we can put them on the DVD. Others we can't. [13:24] Check the licensing, and see if it's freely redistributable. [13:25] well i do have a network cable [13:25] but for not so power useres its hard [13:25] altought the same maybe would happen on the desktop [13:25] i will need to try a live cd to see if they shipp the restricted drivers on cd [13:26] * rlameiro rebooting [13:32] persia: http://dl.dropbox.com/u/1333955/net1.png [13:32] persia: http://dl.dropbox.com/u/1333955/net2.png [13:32] persia: http://dl.dropbox.com/u/1333955/net3.png [13:33] this is all i get on a freshly onstalled ubuntustudio [13:33] concerning network [13:35] persia [13:35] gnome-network-admin [13:35] is network-admin [13:35] run it from the cli and look at it [13:35] that is what you have on a fresh US [13:41] That's not enough :( It needs the Connections page. [13:42] * persia hunts changelogs [13:44] rlameiro: It's 10_disable_interfaces.patch, introduced in 2.22.1-6, which is no longer needed because of the package split in 2.29.1-0ubuntu1 [13:44] Unfortunately, nobody caught that until today. it's trivially fixable, but not for lucid. [13:44] so you need network manager for it.... [13:44] No. [13:44] You just need to fix the bug. [13:45] no, at the moment [13:45] not in the future [13:45] Ah, OK. [13:45] hmm, would a FFE work for this in lucid persia? [13:45] on a RC? [13:45] stochastic: Be a hard push at this point. [13:45] but critical one [13:45] stochastic: Someone might ask why this wasn't caught during RC testing, and I'm not sure anyone has a good answer. [13:46] because people normally install network manager... [13:46] persia, the only real answer is lack of testing - not a very good answer [13:46] I saw that 2 weeks ago [13:46] i didnt knew that was a bug [13:46] i tought i was like it [13:46] RIght, and since it's a package shared with the Ubuntu Desktop, which did get a lot of testing, the RMs would likely ask whether the change might introduce regressions. [13:47] * stochastic installs network manager as the first step to fixing his wireless driver on every install [13:47] rlameiro: If something doesn't work right, please file a bug as soon as you notice, and if you think it's critical to fix for release, say so. [13:47] me to stochastic [13:47] pesiA [13:48] persia: i do talked about it, its what i talked about [13:48] network out the box since a month ago [13:48] ... [13:48] ugh, persia you're right, it's just not possible to fix it now, especially because it would change the package in vanilla Ubuntu [13:48] maybe noone listened to me [13:48] stochastic: That's what I think the release managers would say :( [13:48] for sure [13:48] If I was in their shoes, that's what I'd say. [13:48] rlameiro: Did you file a bug? [13:48] RC is finishing [13:49] persia: I didnt knew it was a bug [13:49] I though it was a US choice [13:49] OK. With a bug that's a couple weeks old, we'd have an argument. Currently, I don't think we have one :( [13:49] No, choice was not to install network-manager. Networking is supposed to work. [13:49] the development team in the past has talked about not worrying about networking for studio [13:50] yeah..... [13:50] That's mostly because it just worked. [13:50] There's a difference between networking not being a priority and networking not working at all :) [13:50] very true [13:51] well, the good news is that we're aware of the issue and can instruct users on how to work around the issue [13:52] Indeed. Deserves to be in the release notes. [13:52] And we can file a bug, and fix it for maverick. [13:52] persia, has anyone started writing the release notes? [13:52] Dunno. [13:52] ScottL: Any idea about the release note status? [13:53] I imagine ScottL would be willing to get that rolling when he wakes up. If not, I can possibly assist. [13:57] stochastic: you are missing :D lot of work? [13:58] also there is another problem [13:59] I talked about it i think to TheMuso, not sure who was [13:59] the ubuntustudio controls stills has glade as a dependency [14:00] rlameiro, I'm on my way back, have unfortunately lost a bit of touch while concentrating on some personal issues. [14:00] i think it only needs to take the line away fromthe deb package [14:00] stochastic: i hope everything is ok with you man [14:00] all is well [14:01] are you stil djing? [14:01] stochastic: https://wiki.ubuntu.com/UbuntuStudio/ControlsRedesign [14:01] persia: https://wiki.ubuntu.com/UbuntuStudio/ControlsRedesign [14:01] :D [14:02] DJing less and less. I've recently bought a piano (electric) so my focus has returned to coffee and piano on sunday mornings. [14:02] i really need feed back to know if i push it or not [14:02] stochastic: nice [14:02] I think "Extra Software PPAs" is a bad idea. What can't we do with backports? [14:03] why not [14:03] the idea of the wiki page is to people put the ideas there [14:04] that are only ideas [14:04] Understood. I'm only trying to improve the redesign :) [14:04] I agree with persia on this one. You're welcome to have the idea but I think it's a bad direction for the project to take. [14:04] but if i will try to code that, i really need to know what from the beggining, since i am not a coder, i will need to study it [14:05] maybe its best to have backports [14:05] yeah [14:05] PPAs are extremely unstable and unchecked [14:05] but we should at least point users to ppas that have nice software [14:05] no [14:05] after that they choose if they want it or not [14:06] maybe just links to the ppa [14:06] beginners shouldn't use ppas, that will ruin their systems [14:06] ok [14:06] persia, release notes https://wiki.ubuntu.com/UbuntuStudio/WorkingReleaseNotes [14:06] what about wine vst? [14:06] i had been keeping up with them for a while [14:07] awesome work ScottL [14:08] anyone interested in porting a perl script to python??? [14:08] hehe [14:08] one quick note ScottL, the preempt kernel will only be installed by default in the amd64 IF the ubuntustudio-audio meta is selected during install [14:11] rlameiro, in response to your wine & VST idea, I'm not too keen on that, but if someone has the drive to get that code written I see no reason to not use it [14:12] there is in the audio tweaks [14:12] i dont remeber the name [14:12] shame on me [14:13] Sandie [14:13] http://www.sandgreen.dk/index.php?side=python_uat [14:14] Is there a clear way in which installing dssi-vst doesn't just work? I know YokoZar has been working on that. [14:15] maybe it works [14:16] but the idea is to use wine to run windows vst plugins using asio to jack [14:17] rlameiro, Sandie's script actually has a section that merely installs dssi-vst [14:18] I believe that's entirely what dssi-vst does, and why it was written. [14:18] running wine and asio to jack is much more overhead for a vst than running it on dssi-vst [14:18] dssi-vst relies on libwine to do it's thing, mind you. [14:18] humm [14:18] ok, i never tried it [14:18] okay, maybe it's the same overhead [14:19] Dunno: depends on precisely how much WINE is required the other way. [14:19] Anyway, easier to just install a package than go through any complex configuration. [14:19] And if the package doesn't just work, that's a bug we ought fix. [14:19] I'd put money on the fact that dssi-vst has trimmed some fat in the process [14:19] Trying to shove that into a config applet is just working around the problem the hard way. [14:20] Probably. It's easier to optimise when one has a tightly defined goal. [14:20] I believe dssi-vst is even shipped on the DVD for easy installation (and installed by default with the appropriate task selection) [14:21] (but not on the RC DVDs, because of a bug) [14:21] (which YokoZar is trying to fix) [14:23] some to put into the collective conscious - i've spoken with jdong about backports since some that I was aware of did not make it back into the official backport repositories [14:24] he suggested me maintain our own LTS backport PPA which then could be proven stable and eventually moved into the official backport repositories [14:24] about dssi-vst, isnt that only for VSTi ? [14:24] ScottL, I like the idea [14:25] I don't see the point of a backports PPA. [14:25] It takes *two* testers to get something approved to -backports. [14:25] i need to follow up with an email to him to make sure he is okay if i post our emails to the list [14:25] If we can't get two testers, we aren't providing softward anyone wants to use. [14:26] persia, he mentioned backports team was pretty busy and apologized when i pointed out ardour 2.8.2 and jack 0.116 were ready to backport and didn't make it [14:26] perhaps we should provide an element that will commit to testing backports as such [14:27] what does it takes to test it? [14:27] err. make it into hardy [14:27] install it and see if it works? [14:27] BUT, even if we run two tests we may still need to prod the backports team via email to actually backport it [14:28] rlameiro, basically, yes [14:28] ok [14:28] rlameiro, I also should warn against digging code out of Sandie's audio tweaks program in hopes of adding it to the Ubuntu Studio Controls app, her code has essentially no safety checks or error handling capabilities. Extensive edits would be required. [14:28] Backports needs 5 things: 1) software gets into the development release, 2) someone builds & tests against an earlier release, 3) two people test that, 4) a backporter ACKs, 5) an archive-admin copies. [14:28] so i will need to have always a LTS install to test backports [14:28] i can do that [14:28] I bought a 500gb disk, i can spare 80gb for that [14:28] Note that a backport needs to happen for each release in order, so to get to hardy, one has to go lucid, karmic, jaunty, intrepid, hardy. [14:28] (but intrepid goes EOL soon, so can be skipped once it does) [14:29] ewww, but okay :) [14:29] rlameiro: I'd recommend 4 20GB sections, rather than one 80GB. [14:29] ScottL: That's the process :) [14:29] WTF [14:29] lol [14:30] haha persia, i'm just being a wag [14:30] 4 distro plus my working one?? [14:30] lol [14:30] If someone on this team works with the backporters regularly, and becomes trusted, they may be able to be a backporter. [14:30] my grub menu will be flooded :D [14:30] There is a backporter on the archive-admin team, so that step usually goes fairly smoothly. [14:30] rlameiro: Nothing says you can't use VMs. [14:31] persia, that's was jdong basically intimated (US member -> backport team) but didn't state it outright, kinda followed the US backport PPA -> official backports repository model [14:31] persia: well, like that is really easy :D I can try to test things out for backport if its needed [14:31] saying that "you do it, if it works well...then we'll see about making it official" [14:31] that's my reading of it anyways ;) [14:31] ScottL: I'll recommend working *with* the backporters team, rather than using a PPA, to make it easier to demonstrate knowledge of their process, and speed the first bit :) [14:32] stochastic: what are you talking about error handling? the exceptions on python, or in general? [14:32] I've seen folks get approved as backporters after 4-5 months of working with the team. [14:32] persia, i don't disagree, i'm just reporting what jdong told me, he didn't say no, he just mentioned that it was 90% QA which can happen outside the team [14:33] like i said, i think he wanted this to be a real addition to the department and wanted verification before moving to the next step [14:33] rlameiro, the code is like a blind surgeon that doesn't listen to its co-workers. It can do some nasty things while not completing it's job. [14:34] stochastic, do i need to add that note about "amd64 -rt kernel with audio meta selection" into the release notes? [14:34] stochastic: ok, so in genersl, ive looked in it, it just send apt-get commands and hopes them to work, true :D [14:34] and who will get the notes out where they need to be [14:34] no rt, preempt ScottL [14:34] sorry preempt [14:35] rlameiro: Please don't use system("apt-get install ..."). Use python-apt if you need to do something. [14:35] ScottL, if you can add that clarification that'd be great. I'll post the finalized notes to the website (our website) when release day comes. [14:35] but i just want to make sure everyone understands the expectations, so that something doesn't get not done [14:35] stochastic, righty-o [14:36] persia: I know, Sandie's script is working like that, i was already looking into apt-python [14:36] most of ubuntu uses it [14:36] so, it should also use it [14:39] rlameiro, the apt commands in her scripts aren't terribly dangerous, it's the removal scripts, moving scripts, linking scripts, wine regedit scripts, and so forth that are really troublesome. But essentially it's not paying any attention to it's surroundings, it's just executing what it thinks should be done. [14:42] stochastic: ok, but do you think that this redesign is the right aproach? [14:42] rlameiro, I still don't understand how it's a redesign and not a feature addition plan [14:43] well, redesign on the GUI side [14:43] maybe its a new contols [14:44] I think that would need to be fleshed out more before it can be judged. What's wrong with the current GUI? [14:44] well nothing [14:45] why fix something that isn't broken? [14:45] but if we want to add a lot of things that gui will get confusing [14:45] stochastic: well i see where you are heading [14:45] ok [14:46] so, maybe just adding features to the actuall GUI [14:46] add one bit at a time, when/as confusion begins to rear it's head, then adjust the GUI [14:46] ok [14:46] so what do you think is a priority? [14:47] I really like the archlinux script [14:47] it is really handy [14:47] got a link? [14:47] on the wiki [14:47] I think the priority is to review each potential feature addition for suitabliilty. [14:47] wait a sec [14:47] http://wiki.archlinux.org/index.php/Pro_Audio [14:47] I suspect some of them can be addressed in other ways (e.g. like fixing dssi-vst rather than providing a WINE configurator) [14:47] persia: exactly [14:48] well i was more interest on the script than the others [14:48] that are just ideas [14:48] the script scans the system and check things to put the system at full pottential [14:48] rlameiro, I don't see any script on that page [14:49] what would be nice is if the erros detected could be fixed by the US controls [14:49] Going through that page: "Getting Started" is handled by the default install. [14:49] (and where it's not, we can fix that) [14:49] http://wiki.archlinux.org/index.php/Pro_Audio#Quickscan_Jack_script [14:49] The only interesting part of System Configuration is the limits.conf stuff. [14:50] and the disk optimizations [14:50] Running JACK is a matter of sane defaults. [14:51] (plus the instructions on that wiki page are outdated: see bug #538702) [14:51] Launchpad bug 538702 in qjackctl "Comply with jackd >= 0.118.0 which now runs in real-time mode by default" [Medium,Fix released] https://launchpad.net/bugs/538702 [14:51] Someone ought check if firewire just works out of the box (I forgot to test for jaunty). It ought. [14:51] yeah, i dont want to use this script [14:51] just the bits we need [14:52] jack flash is better handled with the planned pulse/jack stuff [14:52] for instance rtirq checks for firewire cards ??? [14:52] Realtime kernel is -rt, and I thought I read that irqbalance was installed by default on the server: we could add it if it helps. [14:53] rlameiro: What does rtirq checks on FW cards do? [14:53] persia, the bug you listed, that is JACK setting it's own audio.config (or whatever file) and therefore we don't have to moderate limits.conf right? [14:53] persia: IRQ conflicts [14:53] if so we should put that in the notes as well and publish in forums, -user mail list [14:53] for instance my firewire shares IRQ with my wireless card... [14:54] ScottL: No, that's JACK trying to do realtime by default, so changing the sense of the qjackctl stuff so users can turn off realtime if they like, rather than having a useless control. [14:54] We might be able to have JACK set limits.conf, but that would require more discussion. [14:55] Environment variables should be unnecessary, as we have common agreements based on the various packages that provide the various bits. [14:55] rlameiro: Hrm. That might be interesting, but I think I'd rather see a general configurator, rather than something studio-specific, and then guide users to try it if they need to tune performance. [14:57] persia: are you talking of making a "general controls" for ubutnu wide ? [14:57] or just point at command line how tos? [14:57] No. Just for IRQ adjustment. [14:57] well IRQ settings are intittled for studio matters [14:57] rtIRQ script was made with audio stuff in mind [14:58] by the same guy that made qjackctl, qtractor, etc [14:59] stochastic: did you ran the script? [15:00] persia: also, rtIRQ already comes on ubuntustudio [15:09] sorry, was away with kids, i understand what you are saying about that bug persia [15:10] but should we have concerns about jack setting it's own setting in //etc/security/limits.d/audio.conf ? http://www.pubbs.net/201003/linuxaudio/9816-lau-changing-for-editing-etcsecuritylimitsconf-in-debian-testing-ubuntu-lucid.html [15:10] it says something about it conflicting with /etc/security/limits.conf i believe [15:15] if this is the case then we really should make users away of it [15:29] I don't have /etc/secuirty/limits.d/audio.conf on my lucid install, but agree that's the way to fix it. This deserves a bug for maverick. [15:31] Let's see if it blows something up in lucid: if there are a number of complaining users, we can look at an SRU *after* fixing it in maverick. [15:31] i have i [15:32] *it [15:32] Have what? [15:32] A conflict between /etc/security/limits.d/audio.conf and /etc/security/limits.conf? [15:32] /etc/secuirty/limits.d/audio.conf [15:32] oh [15:32] Please dpkg -S it, and share which package created it. [15:32] i dont have conflicts [15:33] Good! No conflicts is ideal :) [15:33] but there are a lot of tuttorials and how to pointing to /etc/security/limits.conf [15:36] They are outdated. Most documentation gets that way. Search engines are more likely to point to outdated stuff, because there are more likely to be outdated links to outdated docs. Users who try the outdated stuff and find it still helps, will link to it. Users who try the outdated stuff and find it's horrid will link to it. Both of these actions make the outdated stuff more likely to appear in search lists, which then causes users to [15:36] find it, and comment on it, etc. [15:42] i will start working through our documentation about it and comment, as well I will post to the -users list and forums. but first i will append the release notes [15:42] stochastic, note this ^^^ in case you have already started putting the release notes out somewhere [16:03] stochastic, release notes updated [16:08] later today i will start searching wikis and pushing information to -user and forum [16:48] doh, /etc/security/limits.d/audio.conf vs /etc/security/limits.conf also effects ubuntustudio-controls, i suppose we will need to address that during maverick as well [16:52] Yep. [16:53] The release note is mostly "Don't change this setting", I think. [16:53] But we've clearly not been on top of lucid. Maybe we only want to give it 18 months of support? [16:53] (we don't *have* to do LTS) [17:23] persia, think of this in the paradigm for new user accessability and tell me where i fail ;) [17:24] add a line to rc.local to run a script which checks to see if a value is either 1 or 0 [17:24] You've gotten too complicated already :) [17:24] if the set value (default to 0) is 0 then it starts ubuntustudio-controls [17:25] oh, you serious? [17:25] Yep. [17:25] okay [17:25] Even I try to avoid fiddling with rc.local because of the significant opportunity to make a system unbootable. [17:25] What are you trying to accomplish? [17:26] the idea would be present a place for a new user to see some important configuration settings [17:26] and perhaps provide some links to important documents [17:26] which would require clicking a radio box to stop it from being shown on boot [17:27] it's not important at this time, just brainstorming ideas about adding ubuntu/linux ignorant new users [17:27] Too late for lucid. [17:27] For maverick, add it to the default session, and give it the ability to remove itself from the session when a preference is changed. [17:27] oh, yeah...didn't expect it for lucid, probably not even for maverick to be honest, but mav+1 perhaps [17:28] Critically, you want it to run at user login, not at boot. [17:28] Easy for maverick, if the application exists. [17:28] I like the idea, but the implementation was overengineered :) [17:28] i'm hoping to leverage rlamerio for that part, perhaps part of the ubuntustudio-control moderations [17:29] yes, i have that trouble at work, i'm supervisor for engineering department and i tend to tell people not only *what* to do but also *how* to do it [17:29] but sometimes it's not the right *how* [17:30] plus also people need to find their own solutions to learn and grow [17:30] so i often don't just put forth an idea, but also the implementation [17:31]