[01:39] TheMuso, my attempt at fixing the gnome-classic xsession has failed, i will talk with didrocks tomorrow about it [01:39] ScottL: roughing out some of the controls work -- this'll be cake [01:39] ScottL: if I put some time into it over the weekend, I can slam it out with time to have a beer [01:40] paultag, awesome! i look forward to seeing it [01:40] ScottL: righto! [01:40] * paultag goes back to work [03:03] ScottL: ping? [03:07] paultag, pong [03:07] ScottL: :) [03:08] ScottL: Is there a full list of all the things you want to see on this app? I just hunted a graphic designer for this, so we can do a bit more [03:08] ScottL: https://wiki.ubuntu.com/UbuntuStudio/SettingsApp/Redux [03:08] ScottL: I've jotted what comes to mind there [03:10] paultag, this is what we have, it's pretty jumbled but i was cleaning it up: https://wiki.ubuntu.com/UbuntuStudio/ControlsRedesign [03:10] ScottL: what about wild-fantisy stuff? [03:10] i was migrating it to there from this one: https://wiki.ubuntu.com/UbuntuStudio/ReleasePlanning#Ubuntu%20Studio%20Controls [03:11] paultag, i hadn't really thought that far outside the box to be honest becuase i was worried about getting this much done :P [03:11] but i thought it might be a good place to do any config stuff for audio [03:11] ScottL: roger. I'll cherry pick from there. doctormo and I work well together ;) [03:11] maybe we can brainstorm a few more ideas with holstein, ailo__ , astraljava [03:11] _1 [03:11] +1 * [03:14] cheers, thanks ScottL. I'll send you updates as they happen [03:14] paultag, so what is doctormo doing with this? [03:14] ailo__: I'm jacking devel on the settings stuff ;) [03:15] ScottL: He and I will both do GTK. I'll do low(er) level code in python ( settings interfaces, etc ), while he does icons and makes everything cosmetic [03:16] ScottL: it will let me focus on getting it done, while he bitches about how it's unusable ( until it is ;) ) [03:16] paultag, LOL...but aye, he's good with icons and graphics [03:17] ScottL: we're great buddies, he and I are both in Boston [03:17] having him help is a boon [03:17] ScottL: we go for tea now and again [03:17] ScottL: yeah, for sure [03:17] paultag, are you in a loco? [03:17] ScottL: Yeah, -us-ohio -- I was contact until two months ago [03:17] ScottL: I'm also on the loco-council ;) [03:17] i believe he's british, are you british as well, or do you just enjoy tea with a friend :) [03:18] ScottL: he lives in Boston, MA now ;) [03:18] which is where I'm from [03:18] so when I go back home, I meet up with doc-mo [03:22] hey ScottL [03:22] heyya doctormo :) [03:22] paultag is trying to explain to me what options are needed for this new setup tool [03:22] ScottL: we were just talking in PM, figured we'd drag you into this [03:23] https://wiki.ubuntu.com/UbuntuStudio/SettingsApp/Redux#preview [03:23] But the settings as documented appear to be install time settings which should be done there. Not in an extra tool. [03:24] doctormo: iirc one of the issues was a DVD install vs migrating an Ubuntu install via metapackages [03:25] doctormo: you should be able to install ubuntustudo-desktop and get it, and not just have to use the DVD installer [03:25] IIRC, that is [03:25] Yes, I understand that. [03:25] k [03:26] hi doctormo [03:26] * ScottL was talking with the wife [03:28] doctormo, many people also start with a vanilla ubuntu install and just install what they want/need from ubuntu studio as paultag pointed out [03:29] oh, the package name is actually ubuntustudio-controls [03:30] paultag, doctormo : the extra software bit probably may not be a good thing at this time, many felt that this was a bit dangerous [03:31] ScottL: righto. Let's remove that bit,t hen [03:31] then * [03:31] ScottL: Are there controls which can/should be toggled? or is this a one way thing? [03:31] doctormo: the rtprio / memlock need to be massaged [03:31] doctormo: usually. but once it's set right, it's OK [03:32] So that's a set once, never touch again type thing? [03:33] doctormo: if it's set right, yes. If it's set wrong ( and it locks up yoru system ) you need to tweek it [03:33] dangerous then eh, I take it you tweak it with a livecd? [03:33] doctormo: I rawdog it. It's tough to cause any real huge issue [03:34] doctormo: just reisub it [03:34] language I don't understand! [03:34] (if the rtprio is set too high, it sucks all the cycles ) [03:34] doctormo: alt + sysreq + {R, E, I, S, U, B} [03:34] doctormo: that resets your machine nicely [03:35] doctormo: but works even with a total lock ( short of a kernel panic ) [03:37] doctormo: regardless, I see this as a userspace app, the more I think about it [03:38] paultag: Design wise, it's not. Unless you have further data. [03:38] doctormo: how is it not? What if you add a user? [03:38] doctormo: what if you want to switch from rt to lowlatency later on? [03:38] does rtprio need to be set for each user? [03:38] doctormo: or change the rtprio [03:38] doctormo: it can be, but it does not need to [03:39] Consider sane defaults with cli tools to control the complexities if required. [03:39] doctormo: again, that won't work for migrating installs [03:39] doctormo: you have to install, set up a user, apt-get install the metapackages, and you can't touch /home in packages [03:40] Sure it will, you can have post-inst callouts on a package attached to the meta package to do the work. [03:40] doctormo: no, I mean, /home does not exist for packages [03:40] doctormo: if it touches it, it's far out of spec [03:40] Yes you can touch home in packages... technically speaking the current user. [03:40] doctormo: no, you can't [03:40] doctormo: that's wildly against policy [03:40] Then there are a whole host of naughty debian packages. [03:40] doctormo: no there are not [03:41] lol, ground control? [03:41] doctormo: in what case does a package touch /home/user/* [03:41] doctormo: that seriously writes stuff to /home/*/* ? [03:41] You can't touch /home in packages, because FHS says /home is OPTIONAL. [03:41] +1 persia [03:41] The installer restarts nautilus, albeit on the users say so [03:41] doctormo: that's running a command that sends a signal [03:41] persia: I defer to you, [03:41] You can, if you insist, have postinsts that use getent or similar to modify things in user home directories, which is subtly different. [03:41] doctormo: that does not touch /home [03:42] persia: even that should be handled on the application level iirc [03:42] paultag, Depends on the package. For something like ground control, it's better to use the install notify hook to ask the user to restart nautilus (or similar). [03:42] Use of wrappers is more common. [03:43] persia: sure, but the app it's self will init the files in ~/ [03:43] persia: not the package [03:43] OK chaps, off to bed, paultag figure out what fields you need and update that wiki and note me. I'll have a crack at a mockup for you. [03:43] doctormo: cheers, thanks [03:43] doctormo: tea when I get back ;) [03:43] aye aye [03:43] doctormo, thank you for the help [03:43] if [ -f $HOME/.config/myapp ]; then myapp; else; cp /usr/share/myapp/config $HOME/.config/myapp; myapp; endif [03:44] ScottL: Of course, I still owe you some kind of wacom tool, and if it were possible to configure wacom instead of just creating a xinit script with commands in it, it'd be done ;-) [03:44] paultag, i'm terribly excited to see what you chaps come up with, and i know the users are excited for improvement as well [03:44] persia: yeah, but that looks like a script that's calling myapp -- and can be run when you run the command [03:44] paultag, Depends. Packages that have dedicated users for some reason may need to do it in postinst. When dealing with real users, yes, better to use a wrapper (better support for later adding users, etc.) [03:44] ScottL: :) [03:44] persia: aye :) [03:44] Yeah, that's a wrapper script :) [03:44] Ahhh, yes [03:44] that's how I do it with fluxbox :) [03:46] thanks for the help persia :) [04:26] hi troy_s , i talked to quadrispro about that app you mentioned needed packaging and he's interested but just asked me to remind him later as he's busy at the moment [04:27] ScottL: rexbron is almost there I believe. [04:29] troy_s, oh, that's cool then [09:30] ScottL, we have a big problem with ladish's licensing [09:31] persia, could you give me an opinion? http://paste.ubuntu.com/558457/ [11:25] quadrispro, What is the "Academic Free License version 2.1"? [11:26] persia, http://opensource2.usrbinruby.net/licenses/afl-2.1.php [11:27] And why do you mention "* This file contains D-Bus methods helpers"? Are those under separate license? [11:27] persia, it is solved, upstream meant to cover some portions of the code by dual-licensing [11:27] persia, libdus is dual-licensed, too [11:28] OK. So, here's my summary recommendations: [11:28] * quadrispro hasn't noticed it before, really [11:28] http://packages.debian.org/changelogs/pool/main/d/dbus/current/copyright [11:28] 1) You should identify what files are covered by which licenses [11:28] done [11:28] 2) You should make clear that dual-licensed code is dual-licensed [11:29] 3) You should include the *complete* text of afl-2.1, as it is not in /usr/share/common-licenses/ [11:29] 2. reported upstream, and he says that it will be clearly stated in the next release [11:29] 3. done [11:30] For 2) if you have that from upstream, and you know which files are licensed how, you can just report that in debian/copyright, rather than waiting for the next release (unless it's very soon) [11:34] I'd prefer to have a public statement which clarifies that. Upstream seems very collaborative, he's going to publish a small note on the website in the next few hours, too [11:34] Ah, the small note will be hugely useful, indeed. [11:35] though, we need to introduce an important change to jack to make ladish work fine [11:35] Indeed, which was a stumbling block for the longest time, and, if I recall correctly, one of the reasons nedko went to work on JACK2 upstream. [11:37] AFAIK, first of all jack needs to compile with a sort of no-self-connect option enabled [11:38] to avoid conflicts between apps' self-connecting feature and LADISH's session management [11:41] Um. That doesn't sound ideal: there's been a lot of effort to make JACK "Just Work" by enabling self-connect. Do you think that we can get enough documentation that users won't be annoyed, or set up some sort of initial auto-connect with ladi? [11:47] documentation is never enough :) and yes, it would introduce several complications [11:48] I need to send Adrian all information I've collected [13:53] So, what still depends on the "audio" group? My understanding is that most stuff has evolved to no longer depend on this, and if we can find out what is outstanding, and clear the rest, that is probably better than making sure users have an easy way to be added to the group. Part of "Just Works" :) [14:50] persia: i thought that the real-time time privileges given when adding the jack package depend on being in the audio group [14:50] also i thought the new udev rules for firewire depend on the audio group [14:51] oi, i thought ubuntu.com and launchpad.com were slow...however, kernel.org must be on dialup in the antartic [14:52] persia: https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Permissions_and_ownership_for_.2Fdev.2Ffw.2A shows that it depends on video group but i believe ailo looked into this and found that it was the audiog roup [14:52] of course i could be mistaken [14:53] abogani: good morning! i notice that the kernel blueprint for natty is complete with one notable exception, getting documentation for kernel derivatives/flavour into the repositories [14:54] Depends on the udev rules, really. Should be possible to consolekitify it, I'd think. [14:54] abogani: hopefully we see something soon and in time for natty [14:54] persia: i will defer to your knowledge and judgement on that as i know practically nothing about consolekit [14:54] May be best to just upload something, really, and fix it later. Last time I checked with apw, he said that the team had lost a lot of folk, and was having trouble getting all their work done (which is why the doc isn't published yet) [14:55] persia: upload kernel to the repository? [14:55] Sure. [14:55] Maybe best to stick with the group for now then. I suspect it's fixable, but it may be non-trivial, sadly. [14:56] abogani: ^^^ please note that persia is advocating uploading your -lowlatency kernel into the repository, unless i am misreading [14:57] Indeed I am. Waiting further just gets annoying, although without the document, there may be work to do later to bring it into compliance. [14:57] but waiting longer also risks not getting the kernel into natty [14:57] which is bad i should add [15:04] Indeed. [15:12] There's now udev rules included for firewire with the standard Ubuntu install in /lib/udev/rules.d/69-ffado.rules which point to Audio group [15:12] 60-ffado.rules* [15:13] It should really be richer than that. Audio interfaces should be granted permissions similar to USB/PCI/etc. audio interfaces. [15:13] But those are only for realtime, what I understand [15:13] Storage devices should be given extremely restrictive permissions. [15:13] Video devices should be granted permission as needed (I don't have enough knowledge of how video processing works to know if this is restrictive, group video, etc.) [15:14] The firewire device should work without editing, and using no realtime with jackd [15:14] We tested firewire, and this is what we have found, so far [15:14] Sure, but with juju+udev, we no longer need have a single policy for all devices: we can have a per-device policy, based on what the hardware actually does. [15:15] There is per device policy in the 60-ffado.rules file [15:15] ailo: did you specifically test if the user does needs to be in the audio group (i.e. does performance degrade if the user is not in the group?)....i don't current remember if you did or not [15:15] But still, only for realtime, as what I can understand [15:16] After a quick test firewire worked without realtime and no audio group [15:16] hmmm, interesting [15:16] With realtime and no audio group, jackd would crash [15:16] That's a bug, and ought get sorted. [15:17] We only need to be in audio group to get full performance on Natty [15:17] Or, what the drivers and such will allow [15:17] But why? If JACK is crashing, there's a bug in JACK that ought be fixed. [15:18] Haven't confirmed on a another machine. Holstein had a crash when not being in audio group and using realtime [15:19] OK. We need an apport crash report on that bug, and it oughtn't be that hard to fix JACK so it doesn't crash. [15:20] Ok. Let's tell holstein to check it out. [15:20] If there's some permissions issue, JACK may have to send some sort of warning, but crashing is always wrong. [15:20] persia: it fails with dignity [15:20] persia: the app stays alive and opens a message box suggesting to change permissions [15:20] Ah, that's not a crash then. [15:20] persia: +1 [15:26] Ah, ugh. It's a limitation due to limits.conf: the choices are 1) set rtprio for @audio, and put users in the "audio" group, or 2) set rtprio high by default. [15:27] That's it. You don't have to be in the audio group to use JACK in realtime [15:27] Only if PAM is configured like that. [15:27] But you do have to be in that group when you want to use FireWire with the JuJu stack [15:27] Yes, only if PAM is set up for the audio group [15:27] rtprio at least, so pam_limits [15:27] I don't know enough about PAM, but I suspect there's a way to set rtprio for users logging in at console, and not for remote users or system users, which would seem to better match "Just Works". [15:28] Yes that's possible [15:28] Yes, that's how we do it in Ubuntu today, with pam_limits and limits.conf [15:28] Do you know how? [15:28] you can set that in the /etc/pam.d directory [15:29] Do you know what config needs to be dropped there to make pam_limits set rtprio for the local logins only? [15:29] (we'd also want to set memlock, but that's a trivial extension once there is an example for rtprio) [15:30] Just a sec, I know a bit of PAM but I am no guru either ;) [15:30] Thanks a lot for looking into this! :) [15:32] grep /etc/pam.d -lr -e "pam_limits" [15:33] That will give you a list of authentication stuff that uses pam_limits [15:33] I suspect we want it for gdm/kdm/gdm-autologin at least. Maybe some others that I'm not seeing immediately. [15:34] But looking (for example) at the gdm script, I'm not sure how to set specific pam_limits config there, only in the case where that is the source of session initiation. [15:36] by adding conf=/path/to/limits.conf [15:36] Or /path/to/limits.d/gdm.conf for example [15:37] It will override the default settings [15:37] So something like "session required pam_limits.so conf=/etc/security/limits-rtprio.conf" ? [15:37] So if I understand the pam_limits manpage correctly it shouldn't process any other files in /etc/security/limits.d/ [15:37] yes [15:39] * persia reads the manpage again [15:39] The trick is that we *want* it to process the rest of limits.d/ but just add the one special extra config conditionally [15:39] Ah, oh yeah, well, I'm reredinmg it too [15:40] rereading [15:40] "If a config file is explicitly specified with a module option then the files in the above directory are not parsed." [15:40] |If /etc/security/limits.conf has some syntax to specifically include /etc/security/limits.d/, I'd be a lot happier, because then it would be easy. Unfortunately, it's not clear to me how to make it work. [15:40] Right. [15:41] And the above directory is /etc/security/limits.d [15:43] Well, I think if you include the common-* files in /etc/pam.d and put "session required pam_limits conf=/etc/security/limits.d/rtprio.conf" later in the file you should get what you're aiming for [15:44] Ah, but you want it to process everything in /etc/security/limits.d :$ [15:45] Not sure how to set that up [15:48] Forcing conf= seems like it will break stuff for other packages. [15:48] What's the risk of setting rtprio=99 for everyone? [15:50] Not sure, I'm not a security expert [15:50] * persia goes to ask the experts [15:51] But it could lead to programs trying to take advantage of this, setting their SCHED_FIO/SCHED_RR prio to 99 and stall the PC maybe? [15:51] Or am I talking BS here ;) ? [15:51] SCHED_FIFO [15:51] No, but we're making that happen for all our real users anyway: the risk is more about system users. [15:53] PAM does allow you to set optional control values [15:53] What does that mean, in practice? [15:55] That the success or failure of a module doesn't really matter [15:56] How does that help? [15:56] Unless it is the only module associated with a certain service [15:57] maybe it is possible to set a session required pam_limits [15:57] That's the default. [15:57] but also a session optional pam_limits conf=/yadiyadi/ya for gdm [15:59] My fear there is that it might not succeed, which would mean that some users might not get the rtprio setting, and it would be hard to troubleshoot for the support team. [15:59] Yeah, I think you're right [16:00] Since the current support team is 80% holstein, I'm *really* not tempted to do anything that would increase the workload :) [16:25] Seems diwic is already on it: http://comments.gmane.org/gmane.comp.audio.jackit/23110 [16:43] hey guys [16:44] is it ok for me to build abogani's low-latency kernel for lucid and maverick ? [16:44] quadrispro: ping [16:49] lol persia , that should be holstein's tag line..."Holstein: 80% of the support team" [16:49] falktx, pong [16:50] quadrispro: hey [16:50] quadrispro: laditools is ready now, right? [16:50] falktx, ready and uploaded [16:50] oh, quadrispro and persia, i saw your discussion on the licensing this morning [16:50] falktx, but we won't have gladish until piem uploads new flowcanvas [16:50] quadrispro: we dont need the most recent one [16:51] quadrispro: flowcanvas v0.6 works fine [16:51] falktx, moving to #lad [17:08] falktx, back here :) [17:09] falktx, but sources in src are all QT4-based [17:09] k [17:09] and? [17:10] ah no, now I understand [17:10] quadrispro: what is the problem about qt? [17:11] no particular problems [17:12] and I'm noticing that it's just a frontend, so no modules get added [17:12] looks good [17:12] quadrispro: check the 'keyboard.py' thing! [17:13] however, we should wait to have ladish in the archives first [17:13] quadrispro: yes, of cource [17:13] falktx, yes, looking at it right now [17:13] quadrispro: my app is not even beta right now... [17:14] falktx, ok, I'll stay tuned ;) [17:14] quadrispro: the keyboard doesnt act by mouse, only by keys [17:14] falktx, why not help this poor guy in writing a small bunch of manpages for ladish? :) [17:15] hi scott-work persia [17:15] quadrispro: i dont really know how to write manpages... [17:17] falktx, it's easy, just a bit tedious :) [17:17] quadrispro: btw, i made a (complete) patch for mumble jack support [17:18] falktx, please take a look -> http://goo.gl/Dn9R1 [17:19] falktx, ah mumble, I remember we had a chat about it [17:19] but please get in touch with the Debian VoIP team [17:20] quadrispro: better, I'll send upstream [17:20] of course the right way [17:41] bye guys [18:31] damn it I hate natty now [18:32] everything fails to build!! [18:32] arrrrg [18:48] why are they failing to build? [18:49] link error, like composite did [18:55] persia scott-work lol [18:56] i'll read the scroll-back here in a bit [18:56] about that test [18:56] i got some new mics i want to check out for a bit though :) [19:33] falktx, After reading http://liw.fi/manpages/, I've suddenly found it really easy to write manpages. I highly recommend it. [19:34] persia: nice! thanks [20:41] oooh, a new bookmark :) [23:53] thanks for the persia for the direction and help today [23:54] No problem. I haven't seen diwic around: I recommend chasing up with him about getting JACK to use rtkit so we don't need the limits.conf hack or the audio group (because it may well fall out of my working set before it happens if I don't catch him soon).