=== Pretto is now known as malassombrado === malassombrado is now known as Pretto === noy_ is now known as noy === asac_ is now known as asac [07:01] Hi everyone. Who all is here for the Ubuntu Studio Developer's meeting? [07:02] Hey stochastic. [07:02] hey TheMuso [07:03] TheMuso are we the only two here? [07:03] stochastic: So far. [07:05] Well should we proceed with discussion of the agenda? [07:05] https://wiki.ubuntu.com/UbuntuStudio/Meetings/2009Nov9 [07:06] Since there is only the two of us atm, I don't really feel like going through it, since I've just had a day of work. If others were in attendance, I'd be ok with it however. [07:06] ö/ [07:07] stochastic: However if you want to, thats fine with me. [07:07] stochastic: go for it [07:07] hi jussio1 [07:07] * jussio1 slaps whoever invented mornings... [07:08] well since jussi is here now, I think it's worth at least skimming through the topics [07:08] ok [07:08] so Discussion of Karmic [07:09] are users happy? [07:09] there were lots of upgrade issues I heard about [07:09] * TheMuso thinks so, overall. It doesn't help that we have some users giving bad information to help others out of a bind. [07:09] as long as the RT kernel works, most users are happy. [07:09] yeah, in general people like Karmic [07:09] stochastic: Well since we don't have enough man power to even test fresh installs, I am not surprised users have upgade issues, since we don't really test it. [07:09] how is it running? whats the status? [07:10] jussio1, you mean the RT kernel? [07:10] jussio1: Overall the RT kernel is doing very well. I think a few users are having issues with suspend/resume, but we don't promote that as something we support. [07:10] yeah [07:10] TheMuso: ok, great. [07:11] * jussio1 is a little bit out of stuff atm. [07:11] has any user reported the Swami thing? [07:11] Well I made a note during karmic that swami needed updating, but never got back to doing it. [07:12] yeah, okay, I haven't heard anyone saying that the soundfont support is broken in any way [07:13] anything else to say about Karmic? [07:13] not from me [07:14] Okay Lucid: [07:14] Jack into Main [07:15] what are we needing to do at this stage? wait for some debian syncs? [07:16] TheMuso, jussio1, are you two planning on helping with this move of jack into main? [07:17] stochastic: not overly, there are others who are interested. Ive many many things on my plate atm. Although I may be able to do some testing if required. [07:17] stochastic: Yes, I need to review all the pieces first, and take appropriate action, will take care of it once initial merges/syncs are out of the way. [07:17] TheMuso, okay great. I think libffado may need a sync request. [07:18] TheMuso should a schedule be built for this project? [07:19] stochastic: I don't think so. [07:20] okay, anything else need to be said about Jack in Main? [07:20] nope [07:21] okay I put growth in Graphics and Video metas on the agenda because I'd like to see a more balanced userbase [07:21] No omment, not a user of these [07:21] comment [07:21] I just add/remove whats asked for. [07:21] fair enough [07:22] hrm [07:22] I think we have to cater to the users out there. [07:22] I'll consult with some people on what new possible tweaks we might offer. The Video package might see some stable and user friendly editors coming in Lucid. [07:23] jussio1, you mean our current userbase? [07:25] okay, well constant meta package consultations need to be looked into anyway [07:25] stochastic: I mean that we need to check that we have users actually using the features we offer. if not, we need to consider dropping some. [07:25] true [07:25] jussio1: Agreed, disks are big as it is, if we can cut them down as much as possible, then that would be good. [07:26] Perhaps some sort of user survey or something is in oreder. (havent really thought it through) [07:27] Should we plan on sending an e-mail to the users list to gauge interest in applications? [07:28] I'll happily do this. [07:28] sounds like a good idea [07:28] stochastic: email might be a bit long, given how many apps we ship [07:28] perhaps an email with a wiki link? [07:28] or somethign similar. [07:29] jussio1, okay that might work too [07:29] but yeah, some sort of user feedback is important. [07:29] okay anything else to say on this topic? [07:30] no [07:30] I think we can safely skip over the next two agenda points "updated packaging whishlist" and "motin's suggestion regarding using the ubuntustudio ppa for jack package testing" [07:31] right [07:31] anyone want to talk on those points? [07:31] the next item is Kernel Plan [07:31] We don't know what mainline kernel will be used for lucid yet, so can't do anything else till we know that. [07:31] thats pretty much it atm. [07:32] fair enough [07:32] next item is Ubuntu Studio Controls [07:32] is there a reason we cant stick with an older kernel? [07:33] jussio1: It breaks different pieces of the userspace stack in weird and wonderful ways. [07:33] :( [07:33] hrr [07:33] jussio1: We had a mis-aligned alsa stack in hardy, and it broke things in painful ways for some people. [07:33] right. moving n then [07:34] Alex has recently expressed in a need-packaging bug that he's too busy right now to devote much time to Ubuntu Studio so I don't imagine he'll be around to help with Controls updates [07:34] right [07:34] alex? [07:34] rexbron [07:34] s/alex/andrew/ [07:34] whoops [07:34] sorry [07:35] np [07:35] Is Luis knowledgeable in the Controls code? [07:35] I believe so. [07:35] Cory was saying Luis and Andrew should be penned in to migrate Controls to GTKBuilder [07:36] its python anyway, and not too large, so if we can find a new someone they could learn reasonably quick. [07:36] but we also have a number of Controls bugs we need to tackle. [07:36] I'm partially knowledgeable with the codebase [07:36] a new developer would be a great thing [07:37] right [07:37] jussio1, do you have anyone in mind? [07:38] no [07:38] okay, well in conversations with everyone keep this project in the back of your head [07:38] anything else to say on Controls? [07:40] no [07:40] Next on the agenda is the artwork to be used project-wide, but Cory isn't around. I trust he has a plan. [07:40] I sure am glad Cory has time to work on this [07:41] last Lucid-specific topic is "What elements need to be added to https://wiki.ubuntu.com/UbuntuStudio/LucidTaskList " [07:42] I think we need to announce this page a little bit and try to get new team members to chip in a bit through those projects. [07:42] yes. [07:42] right [07:42] agreed [07:42] and we need to be a little more open with "team membership". it needs to be a little less "exclusive" so people feel more comfortsble contributing. [07:43] The ubuntustudio-dev team? I don't agree. [07:43] The team has write access to seeds and packaging branches in bzr. [07:43] IMO one has to earn their access to that data. [07:43] TheMuso: I dont mean adding people to it, but there needs to be something further for casual contributors - similar to erics testing team [07:44] jussio1: Ok thats fine then. [07:44] speaking of the Testing Team, that's the final agenda topic [07:44] Cory was the only one to speak out with any form of opposition/critique on the mailing list [07:45] I am fine with it. [07:45] big +1 from me. [07:45] Okay, I'll go ahead with the plan and we can talk about how successful it is as it progresses [07:46] Ok great. [07:46] Can I assume I should subscribe ubuntustudio-dev as members of the testing team? [07:46] yup [07:46] great. [07:46] anything else to say before we ajourn the meeting? [07:46] not fro me [07:47] nope [07:47] oh, we need to sort out a re-scheduling of meetings [07:47] not enough of us here to make a decision on that [07:47] I guess the Mailing List is the best medium for that [07:47] I can be flexible with those times, so I'd rather leave it up to others [07:47] s/those times/times/ [07:47] okay [07:48] jussio1, you have any preferences? talk was about moving the meetings to Sundays [07:50] Well I think we can cal the meeting over now. Thanks for showing up TheMuso and jussio1. [07:50] stochastic: np thanks guys. [07:52] stochastic: this is ok. euro day is generally good. [07:53] jussio1, okay I'm sure we can work around that. Watch for announcements/discussions on the mailing list [07:53] ttyl [07:55] good morning === dholbach_ is now known as dholbach === imlad|away is now known as imlad === dantaliz1ng is now known as dantalizing === fader|away is now known as fader_ === marjomercado is now known as marjo === imlad is now known as imlad|afk === robbiew_ is now known as robbiew === asac_ is now known as asac [18:05] * robbiew waves [18:05] heya [18:05] hello [18:05] oh === asac_ is now known as asac [18:06] ok, quick weekly review then to UDS topic/session/todo items? [18:06] I've got openjdk-6 updates coming from doko, and will push for getting a kernel update rolling [18:07] I'm going to be examining our CVE tracker data and tweaking a bunch of stuff to better reflect reality so the new graphs don't make it look like we're slackers [18:08] and I'm on triage. [18:08] that's it from me. jdstrand up next [18:08] o/ [18:08] * jdstrand for some reason thought the meeting was an hour from now... [18:09] I'm in the happy place [18:09] I plan to continue to follow-up on/file SRUs this week [18:09] poke at redhat-cluster, and a couple of other security updates assigned to me [18:10] I should have a firefox update again this week [18:10] and then UDS preparation [18:10] that's it from me [18:10] my turn [18:10] I'm working on openldap. [18:10] that'll take a while [18:11] and will spend some time preparing for UDS topics [18:11] that's it. [18:12] ok, cool. robbiew before we hit the UDS idea list, do you have anything to add to it, or other topics to go over? [18:12] nah..you're good ;) [18:12] I just added a bunch of non-session/work-items for me, so be sure to refresh the page [18:12] okidoky [18:12] * kees refreshes [18:12] I suppose I should work on a Security track for next UDS though :/ [18:13] robbiew: we had one at the last UDS. :) [18:13] hmm...let me check then on this one [18:13] "apport hooks (vs https://bugs.edge.launchpad.net/~ubuntu-security/+packagebugs)" [18:13] this is something that bdmurray had called attention to a while back [18:13] basically, if there is an Ubuntu team doing triage for a set of packages, it likely makes sense for those packages to have apport hooks [18:14] so, it might be worth having a session to review those package, and perhaps identify others, that we should build hooks for. [18:14] thoughts? [18:15] yeah, makes sense [18:15] not sure it's uds-session worthy though [18:15] i.e., too much time to discuss it? [18:15] I'm not sure it is security team specific [18:15] right, bdmurray's call wasn't security team aimed, but I figured we could take on his call-to-action within our team [18:15] ie, we are already doing that for the packages we update [18:15] kees: yeah...it's a 10 minute discussion [18:16] mdeslaur: really? I don't think we have hooks for anything listed here except apparmor: https://bugs.edge.launchpad.net/~ubuntu-security/+packagebugs [18:16] though, that reminds me, we should generalize and improve the apparmor hook [18:16] (perhaps none are needed?) [18:17] * jdstrand added that [18:17] kees: oh, well if you feel there's something to discuss, no problem. I thought it was more of a to-do. [18:17] how should we define the work for hooks, then "Create list of packages that have been reviewed for apport hooks, with justification for why they lack a hook"? [18:18] seems fine [18:18] mdeslaur: I figure it'd be nice to review packages that get a lot security bugs, and our subscribed list [18:18] Ok, I'll draw up a session for it and dream of ways to fill 40 minutes. ;) [18:18] kees: oh, yeah, that's a good idea [18:18] that'll fill 40 minutes [18:18] kees: well, really anything that ships an AA profile could benefit from a hook [18:19] * kees nods [18:19] we started to do that, but didn't retroactively add them [18:19] "review sponsorship process and compare to security-sponsorship" [18:19] seems like a good sessino [18:19] session [18:19] this is a request from dholbach to try to merge our sponsorship process to standard processes. [18:20] * jdstrand nods [18:20] I'm really not sure the right approach to take with it, so I agree, face-to-face with dholbach and others would be valuable here. [18:20] " http://fedoraproject.org/wiki/Features/LowerProcessCapabilities " [18:21] I'd like to see us do this. [18:21] I don't think it's a few subtle change... [18:21] I would to, but, aren't we always going to get push back for filestystems that don't support it? [18:21] especially "the shadow file permissions have been changed to 000" [18:21] oh wait [18:21] that was fscaps [18:21] nm [18:21] is it worth doing that, or getting apparmor profiles for those root daemons? [18:22] that could be something we discuss [18:22] I think we should pursue non-MAC methods of hardening along with MAC [18:22] kees: are these patches that fedora is planning to just carry ad infinitum? or are they pushing to upstreams? [18:23] jdstrand: don't know, that would be worth investigating before the session [18:23] is this session-worthy? I think we'd need foundations in on it. [18:23] we could have a session to determine if it's worth doing from a security point of vue [18:24] 000 for /etc/shadow [18:24] man, that is hardcore [18:24] we'd totally need foundations in on it [18:24] that could *totally* break things :P [18:24] 555 for /bin [18:24] jdstrand: well, it would only break for daemons that had specifically dropped DAC_OVERRIDE [18:24] "neat" [18:25] jdstrand: by default, a root-running process has DAC_OVERRIDE [18:25] I'd need to review it more to have a worthwhile opinion [18:25] it seems the list of daemons that _can_ drop DAC_OVERRIDE is very limited [18:25] in the interests of terrifying the foundations team, I think I'd like to make a session for this. [18:25] mdeslaur: yeah [18:26] kees: lol :) [18:26] sounds risky-- perhaps too risky for LTS, but maybe we could review the topic in general, the apps it might affect, and whether or not to pursue it (whether for lucid or lucid+1) [18:26] "the following apps are not confinable: console-kit-daemon, cups, postfix, rsyslog, auditd, audispd" [18:26] those are the ones I _want_ to confine :( [18:26] Insist it's essential for LTS and then reluctantly agree to defer it. They'll owe you then. [18:27] ScottK: heheh [18:27] ScottK: ehehe [18:27] "all deps of ubuntu-desktop and applications in the server CD"\ [18:27] kees: I think it is worthy of a session [18:27] * ScottK will once again opine that confining Postfix is likely more trouble than it's worth. [18:28] okay, cool. [18:28] ScottK: yeah, dovecot is proving painful too [18:28] ' figure out better "screen lock does not work" bug triage process ' [18:28] our session from the last UDS on this topic, frankly, failed. [18:28] yeah *sigh* [18:28] we have an ever growing number of reports about screen locking not working in a wide variety of cases [18:29] kees: we need to get gnome-screensaver maintainers in the session [18:29] we cannot fix them all, much less triage them all. [18:29] mdeslaur: yes [18:29] much less reproduce them [18:29] jdstrand: yeah, true [18:29] at least some seem hardware specific [18:29] yeah [18:30] so, I'd like to focus on getting the right people into that session. I'm not sure who they are, though. [18:30] though, as an aside, I noticed gnome-screensaver won't look if a virt-viewer window has focus [18:30] combination of 1- video drivers, 2- gnome-screensaver bugs [18:30] probably gtkvnc related [18:30] s/look/lock/ [18:31] jdstrand: oh? that's interesting [18:31] jdstrand: yeah, I've seen that too. I'd like to get bug triage involved too, as this sounds like a good candidate for a "DebuggingScreenLocking" or something [18:31] kees: excellent idea...a session to get a DebuggingScreenLocking wiki page [18:32] I suspect we can't reproduce some of the issues because people are running alternate window managers [18:32] mdeslaur: oooh, yeah, that's the best way to frame it. It really is the output we need. [18:32] yeah [18:32] we'd need screensaver devs for gnome, kde and xfce, no? [18:32] yeah [18:32] If it's common enough, maybe also a session with the right people in the room for people to bring borked laptops to for diagnosis? [18:32] at list the first two [18:32] seb should know who the maintainers are [18:32] ScottK: yeah [18:33] so having seb on the session will be of great benefit [18:33] or pedro, the Desktop QA guy [18:33] ScottK: excellent idea [18:33] No one from KDE upstream at this UDS, so Riddell is probably your best bet. [18:33] (he's going to thank me for that, I'm sure) [18:33] hehe [18:34] " filesystem capabilities " uhm, I don't have anything more specific than last UDS, so I'm not sure its worth brining this up again. Maybe it's just a TODO to get Debian to start doing it for things that can use it immediately/ [18:34] kees: can't we start it first? [18:35] kees: probably-- aiui, foundations we not too excited due to some filesystems [18:35] mdeslaur: sure, though I'd like to get opinions from Debian, since it's kind of an architectural change, requires dpkg support maybe, tar patches, etc [18:35] mdeslaur: kees can just upload into Debian then do a sync request [18:35] kees: how does that work for you? [18:35] :P [18:35] jdstrand: heh [18:35] hehe [18:35] I hear there are going to be a lot of Debian people at UDS. [18:35] ScottK: cool [18:36] * jdstrand was obviously kidding about the upload/sync thingie [18:36] kees: well, wouldn't wine and dosemu be ideal first candidates for this? can't we put it into postinstall scripts at first? [18:36] or initscripts [18:36] mdeslaur: no, I don't think they should get CAP_SYS_RAWIO. [18:36] mdeslaur: I'm thinking "ping" is the best [18:36] it's already setuid and already drops privs/caps [18:37] if it gets the CAP_NET_RAW it would work with no code changes [18:37] since the kernel prefers fscaps over setuid bits [18:38] Yokozar will be at UDS, so you can certainly talk to him about WINE. [18:38] kees: well, we'd need a better use case than ping to convince people [18:38] Please don't make him too sad as I'm rooming with him and I don't want to have to try to sleep while he's weeping. [18:38] ScottK: yeah, I've been talking to Yokozar at length about the mmap_min_addr stuff. He's going to the Wine conference, where he's bringing it up. [18:38] mdeslaur: you need a safe sandbox to start playing with it anyway [18:39] ScottK: hah [18:39] mdeslaur: so first one, being a sandbox, and the second one your demo to convince people [18:39] ScottK: at present, it seems like I'll be creating a debconf question that defaults to safe for wine. and for dosemu, it's just be safe since they're emulating low memory now. [18:40] ok, doing fscaps as a TODO, chat with Debian, PoC in Ubuntu, etc [18:40] I'll make a blueprint for it, though, since it had some prereqs (tar patch) [18:40] kees: You'll want to make sure that the default GUI package managers support answering debconf questions then (the Kubuntu one doesn't, although it's planned and should make Lucid) [18:40] kees: sounds good [18:40] " forwarding patches to debian BTS for security updates " we're already doing this, iiuc. anything more we need for UDS? [18:41] kees: we sort of do this [18:41] kees: if debian people are there, it would be a good opportunity to ask what we could be doing better [18:41] I think we need to have a policy about how we do it, then state it somewhere [18:41] mdeslaur: true. how can we find out? [18:41] (the people list, I mean) [18:42] kees: #debian-security? [18:42] plus it would be a good opportunity to talk with Debian, and generally let people know we want to dtrt [18:43] kees: regardless of what they say in #debian-security, I personally think we should have a session, and if not a session, the 3 of us need to talk about it [18:43] alright, perhaps we can make it a large-scope session "Working with the Ubuntu Security Team" or "how can the security team serve you better?" [18:43] fwiw, I know Luk Claes from the debian release team will be there...don't know if anyone from debian-security [18:43] jdstrand: ok [18:44] robbiew: yeah [18:44] a generic title like that may not attract the relevant debian folk, though [18:44] kees: eg, iirc, some people require a patch go to debian before they sponsor a patch [18:45] "How can the Ubuntu Security Team help Debian (or other folks) better?" [18:45] :) [18:45] if we are tying into the regular sponsorship process, then we might get more contributors and maybe more back to debian [18:45] jdstrand: yeah, true [18:45] kees: who are 'the other folks'? [18:45] * jdstrand is slightly confused [18:45] You might also consider giving community people upload rights for Universe security stuff. [18:46] jdstrand: upstreams? [18:46] jdstrand: Ubuntu community, anyway. I was just trying to scope the session to "more than just Debian" in case no one from Debian is there/interested. [18:46] ScottK: it's been discussed, and that is the long term goal-- the infrastructure hasn't been there in LP === fader_ is now known as fader|lunch [18:46] ScottK: we're waiting for "real" ACLs in the sourceSync API [18:46] maybe that has changed, I haven't looked at it for some tme [18:47] time [18:47] jdstrand: does that make sense? (other people == anyone, Ubuntu, upstream, etc) [18:47] kees: I just want to make sure the discussion will be the one we want to have [18:47] OK. [18:47] kees: eg, my personal objective for the session is Debian-specific [18:48] kees: the sponsorship session seems ubuntu-community specific [18:48] or, at least, the ubuntu-community bits are part of the sponsorship session [18:48] jdstrand: true, point taken. ok, we'll have it as Debian-specific, in the hopes that there is Debian folks, and if not, we can just brainstorm. [18:48] kees: but if you want it broader, that is fine be me (I just think we can accomplish a lot even without Debian) [18:49] * kees nods [18:49] " protecting select() users when RLIMIT_NOFILE > 1024 http://sourceware.org/bugzilla/show_bug.cgi?id=10352 " [18:49] sourceware.org bug 10352 in libc "no protection against using fd_set with fd>1024" [Normal,Resolved: wontfix] [18:49] kees: whoever's not attending can at least join in on irc [18:49] mdeslaur: are we doing irc this time around? ;) [18:49] this is ... probably just a todo. requires a source search and a massive bug-filing campaign. I will do it via Debian, though it's not a high priority since most services don't run with RLIMIT_NOFILE > 1024. [18:50] jdong: sorry...I don't get it [18:50] mdeslaur: tab completion error? [18:50] any thoughts on this goofy select bug? [18:51] whoops [18:51] jdstrand: sorry...I don't get it [18:51] kees: so it will mean doing a source check for tons of packages? [18:51] mdeslaur: iirc, we didn't have irc input at our last UDS [18:51] Yes, we did. [18:51] mdeslaur: perhaps I was the only slacker who didn't pay attention to it [18:52] jdstrand: oh, your internets were busted :P [18:52] nxvl: yeah, a) generate list of all sources that use select() with a listen()/accept() b) see if they correctly deal with fd_set being >1024 fds. c) file bugs [18:52] ScottK: I don't recall it in any of the session I attended (whether I, the security team, or someone else led it) [18:52] but sounds like I may have just been the only slacker [18:52] Some sessions used it, some didn't. [18:53] kees: yeah, the question is: is there anyway to check if it uses select() without actually looking at the source? [18:53] nxvl: we could look at binaries. :P [18:53] * nxvl smells nightmare [18:53] nxvl: magic wand? : [18:53] nxvl: indeed. :P [18:53] ok, onward [18:53] " using lxc " [18:54] that's LinuX Containers [18:54] we can always get the full archive and run grep :P [18:54] nxvl: we already have a tool that does that [18:54] mdeslaur: yeah, that's what i was talking about :D [18:54] nxvl: right, I have tools that can do this already. it's just that the combo of listen/accept/select is hard to search for [18:54] I have no idea what a session on Linux Containers would look like, but it seriously rocks -- chroot on crack. [18:55] kees: as in using them for what? [18:55] (without kernel patches) [18:55] kees: well, searching only select, build a list, then reduce the scope of the search to just those will be really helpfull [18:55] mdeslaur: yeah, brain storming, I guess. [18:55] not really sure. [18:55] nxvl: true, yeah [18:56] but if there are no idea, we need to skip it. :) [18:56] kees: I want to type something in response to 'using lxc', but don't know what [18:56] jdstrand: heh, yeah, me either. :P [18:56] well, I'll toss this out: libvirt has lxc support [18:57] * kees nods [18:57] that's all I have :) [18:57] NEXT! [18:57] " process limit unlimited (LP: #391761) " [18:57] kees: were you thinking of investigating lxc and perhaps documenting it somewhere? [18:57] I think this might just be another TODO for me to poke foundations (specifically slangasek) about. I was suggesting some ideas to slangasek about this recently [18:58] In other news, I noticed today that it's been over half a year since the last clamav -security upload. Who would have thought such a thing was possible? [18:58] jdstrand: maybe, there's already plenty of docs on using it, though. I was thinking about using it with schroot/sbuild (gains network isolation trivially) [18:58] ScottK: totally! I sure didn't :) [18:58] ScottK: hah! whoa [18:58] We ought to (at some point, not at UDS) discuss the timing for replacing clamav 0.94 in Dapper/Hardy/Intrepid. [18:58] ScottK: will you be at UDS? [18:58] yeah, we did a little the other day [18:58] Yes [18:58] ScottK: excellent idea [18:59] why not discuss at UDS? [18:59] No reason not to. [18:59] Just UDS tends to be busy and that doesn't really NEED a session. [18:59] it certainly wouldn't require a session, afaict [18:59] ok, cool. [19:00] " readdir_r stack smashing (LP: #392501) " [19:00] with the previus experience, security "track" should have half-hour sessions [19:00] :P [19:00] this is... odd and needs investigation, not really a session. TODO! [19:00] kees: whoa, that again :) [19:00] * nxvl is confused [19:00] mdeslaur: yeah, still not solved. I suspect alignment fun in the kernel.... *pokes out own eyes* [19:00] kees: are you talking about clamav or the proces limit thing? [19:01] nxvl: talking about 19:00 < kees> " readdir_r stack smashing (LP: #392501) " [19:01] ohh [19:01]