=== RoAk is now known as RoAkSoAx === asac_ is now known as asac === mc44_ is now known as mc44 === fdd-0 is now known as fdd [13:52] hello everyone [13:52] pitti! [13:54] hey pitti [13:57] hi [13:57] hello [13:59] hm, I can't find Ted online, is he on vac? [13:59] hi [13:59] hi seb128 [13:59] hi mvo [13:59] hey MacSlow [13:59] hi Riddell, Hobbsee === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Desktop Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 09 May 04:00 UTC: MOTU | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team [13:59] hello [14:00] * Hobbsee waves to MacSlow [14:00] hm, Ted is not on vac [14:00] hi [14:00] hi kwwii [14:00] * pitti phones [14:00] no idea what's with ted [14:01] ah :) [14:01] ted2: ah, that's *the* Ted? [14:01] pitti: good morning :) [14:01] ah :) [14:02] ted2: welcome [14:02] hello ted2 [14:02] ted2: it's your evil twin brother! [14:02] https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-05-08 FYI [14:02] Yeah, I'm trying to use Empathy to learn it's flaws... it seems that "tedg" and "ted1" are among the flaws :) [14:03] I didn't see anyone else posting agenda items; did I miss any? [14:03] did everyone have a chance to review their assigned bugs on https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 ? Any problems with those? [14:04] we should solve them soon, we won't have any time in Prague, and towards the end of June we want to start building hardy.1 CD candidates [14:04] doh, that's short [14:05] * MacSlow feels like an idiot working on integrating mipmapping in clutter only to see that yesterday something from elsewhere was pushed upstream [14:05] seb128: well, we still have about six weeks to hammer at it [14:05] pitti: when do we get daily CDs again? [14:06] (for hardy .1) [14:06] so much for wasting time... especially nobody from O-Hand told me they are working internally on it [14:06] mvo: unsure; do you think they'd be useful already? [14:06] mvo: I don't think they are hard to set up, need to talk to Colin [14:06] for me at least yes [14:06] ACTION: pitti to set up daily hardy CDs with Colin [14:06] I have a SRU open with the cdromupgrade script on the server cd [14:06] 18:00 < slangasek> evand: no ETA yet on hardy CD builds [14:06] MacSlow: That sucks, any clue on why? Seems like something they'd be against also. [14:06] mvo: right, we also have some installer fixes [14:07] MacSlow: who's O-Hand? [14:07] thanks pitti [14:07] ted2, no idea... especially since I blogged about it and chatted a bit with Matthew Allum (Opened Hand boss) about the API [14:07] pitti, that's "Opened Hand" the upstream of clutter [14:07] ah, ok [14:08] They also do "dates" and a couple other embedded (sorry mobile) things. [14:08] pitti: enomootbot? [14:08] Hobbsee: don't worry, just convention; I'll trawl through the log anyway afterwards [14:09] pitti: ahhh [14:09] MacSlow: So I guess at o-hand the right hand doesn't talk to the left? :) [14:09] ted2, while the pure GL-side of things was easy for me making a patch out of this against clutter wasn't that easy... spent several days on this... then cogl (internal OpenGL-abstraction of clutter changed) had to move stuff over... [14:10] how do you feel about upgrade failures (maintainer scripts) in universe packages? I would like to still milestone those on the grounds that even they are universe they may break upgrades and give a bad user experience - how is your feeling about this? [14:10] ted2, no clue... but I feel misable trying to work upstream (thus neglecting direct work on the face-browser) just to see that I wasted about two weeks for nothing [14:10] mvo: yeah, that makes sense [14:11] mvo: I recently watched a friend doing a dist-upgrade which was completely wrecked due to python-numpy failing to install [14:11] MacSlow: Yeah, for sure. Are there going to be any o-hand folks at FOSSCamp/UDS? [14:11] mvo: btw, on that occasion u-m immediately crashed/aborted, so that the system was left in a 80% upgraded state [14:11] ted2, yes... Matthew will be there... I will bring that up when talking with thim [14:11] mvo: but there was no possibility to finish the upgrade, nor do the cleanup, etc. [14:11] pitti: was that a server upgrade? [14:11] mvo: how many are we talking about? [14:11] pitti: for the desktop it should continue [14:11] mvo: no, standard ubuntnu desktop [14:12] Hobbsee: so far not that many [14:12] mvo: it didn't :/, it just went away after the failure [14:12] pitti: oh? it skips the cleanup, but it should go on, could you ask him to sent me the logs? [14:12] mvo: as in, 5, 10, 20, 50? And how long do you think i'tll take to find out the rest? [14:12] pitti: went-away == crashed [14:12] Hobbsee: in the range of 10-20 I would say [14:12] MacSlow: argh, that sucks; communication problem? i. e. you didn't know about each other working on the same ting? [14:13] pitti, no... I blogged about that I missed mipmapping in clutter... showed that I had the needed GL-stuff already done and planned to write a patch for clutter [14:14] pitti, I also emailed the clutter-ml regarding how to go about exposing it in the clutter-API [14:14] mvo: sure, I'll ask him [14:14] pitti, so they cannot have missed that I was working on it [14:14] mvo: /var/log/? [14:14] MacSlow: they read your blog? [14:14] pitti: /var/log/dist-upgrade/* please [14:15] mvo: TODOed [14:15] thanks again pitti [14:15] MacSlow: oh, nevermind, ML [14:15] pitti, well I pointed them to it and it gets to p.g.o and p.u.c so there's plenty of exposure [14:16] mvo: so easy enough to hit in one go, if we have a list. *nod* [14:17] MacSlow: how do you think can we avoid that in the future? they didn't take you serious enough or so? [14:17] Hobbsee: some of the failure seem to be a bit icky (haskell for example) [14:17] mvo: oh, we still need to finish the /etc diff for dapper->hardy, too [14:18] pitti, I'll write Matthew an email and ask him [14:18] MacSlow: can you talk to them again and ask him how to avoid that in the future? [14:18] ah, good [14:19] ok, so I went throug the unassigned hardy.1 milestone list and picked out a few which look like falling into our team [14:19] shall we just quickly go through them? [14:19] https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/206998 [14:19] Launchpad bug 206998 in compiz "Screen splited when changing monitor resolution settings " [High,Triaged] [14:19] sure [14:19] iz mvo bog ;-) [14:19] it's not entirely clear whether it's a compiz or an xrandr bug [14:20] I get the issue too [14:20] pitti: right, I worked a bit trying to eliminating some of the noise, I will run another one soonish [14:20] mvo: do you think you can care for coordinating this between the X and compiz upstreams? [14:20] the cursor can go in the area, clicking work etc [14:20] mvo: etc diff> me too [14:20] but compiz consider the vertical line as the viewport limit [14:20] ah, right, I think I noticed that, too [14:20] so I would say it's a compiz bug [14:20] pitti: I can look into it yes [14:20] thanks [14:21] bug 213081 [14:21] Launchpad bug 213081 in linux "CUPS does not print to LPD printer" [High,Confirmed] https://launchpad.net/bugs/213081 [14:21] cupsish, I'll take that one [14:21] * mvo looks at till [14:21] bug 150187 [14:21] Launchpad bug 150187 in poppler "[gutsy] [regression] Evince has very bad quality when printing pdf files." [Unknown,Confirmed] https://launchpad.net/bugs/150187 [14:22] I don't think this one will be fixed easily [14:22] mvo: I have a much better connection to upstream nowadays, I'll manage :) [14:22] it seems to be cairo or poppler [14:22] seb128: right, that seems like a tricky poppler bug, I guess? [14:22] seb128: is that actually a regression from gutsy? [14:22] no it's not [14:22] gutsy had the issue [14:22] it might be a regression from dapper [14:23] I mean, the bug in that generality seems weird to me [14:23] where we were using the splash poppler version and not cairo [14:23] I print out PDFs very often (well, my wife does), and they look fine [14:23] so it affects only some? [14:23] right [14:23] you can assign it to me [14:23] yeah... I never saw issues with PDFs too [14:23] they generally look ok for me too (also I don't pint that much) [14:23] but I don't guaranty it'll be fixed for hardy [14:24] I'll try to talk with upstream about it [14:24] seb128: no, I'd just like milestoned bugs to have someone who is looking into it [14:24] I'm looking at this one [14:24] seb128: if it ends up being unmilestoned because we can't do anything, that's fine [14:24] ok [14:24] seb128: can you assign it to you? thx [14:24] bug 184238 [14:24] Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Medium,Confirmed] https://launchpad.net/bugs/184238 [14:24] *violently agreeing* [14:24] pitti: done [14:25] oh, apparently fixed upstream! [14:25] pitti: mvo has been assigned to the sponsor request before hardy, not sure why he didn't upload though [14:25] pitti: I got jdong to submit the debdiff before hardy, it's just waiting for sponsoring [14:25] * seb128 looks at mvo [14:25] *cough* [14:25] ... [14:25] ah [14:25] mvo: can you take this? or shall I? [14:26] sure, happy to take it now [14:26] seb128, pitti: It might also be the printer. The cairo ouput changed to the point of pushing some printers in the new release. [14:26] sorry - I must have overlooked it before the release [14:26] ted2: that's not a new bug, it was already there in gutsy [14:26] mvo: thanks, assigned now [14:26] mvo: that's alright, that was a string change so tricky, but now let plenty of time to translators to do a good work [14:27] hi OgMaciel [14:27] bug 208097 [14:27] Launchpad bug 208097 in python-aptsources "FTBFS in Hardy due to python-distutils-extra changes" [Medium,New] https://launchpad.net/bugs/208097 [14:27] darn, too late to remove the package from hardy final now [14:27] pitti: even if it doesn't build? [14:27] hey there MacSlow [14:27] IMHO we should just remove it from intrepid and ignore hardy; any objection? [14:27] +1 [14:27] Hobbsee: hardy is frozen, we cannot remove stuff from it [14:27] ok, I'll deal with it [14:28] pitti: oh, i thought you could - as in, that there were reasons why it wasn't a good idea, rather than a technical limitation against it [14:28] +1 [14:28] for reasons like that I like milestoned bugs to have a clear assignee [14:28] Hobbsee: that's pretty much the case, yes [14:29] (I believe, anyway -- who knows how soyuz breaks if someone woudl actually attempt it :-P) [14:29] bug 204770 [14:29] Launchpad bug 204770 in tracker "[hardy] gdmsetup cause intensive disk activity and take a very long time to open" [Medium,Confirmed] https://launchpad.net/bugs/204770 [14:29] pitti: on second thoughts, i suspect it's a *very* good idea not to try. [14:29] seb128: you commented on this, do you have a quick summary? [14:29] Hobbsee: *chuckle* [14:29] pitti: gtkfileselector has a search item which uses tracker [14:30] ooh, that one again [14:30] pitti: :) [14:30] right [14:30] and libtracker api for "is tracker running" autostart this one [14:30] which is completly broken if you ask me [14:30] sudo time-admin or other program, and there goes tracker driving you mad? [14:30] yes, but tracker is disabled in hardy so I'm not sure why that's happening [14:30] I'll consider dropping the gtk tracker support if the tracker guys don't fix the issue [14:31] it doesn't just start tracker, but also gvfs daemons, etc., doesn't it? [14:31] seb128: could we just make the file selector not triggering autostart? [14:31] so that people coudl still manually enable tracker, but it wouldn't start magically any more? [14:31] yeah, I was considering that as well [14:32] not sure whether it's possible [14:32] well, just stop installing /usr/share/dbus-1/services/tracker.service [14:32] seb128: the gdm task is bogus, right? [14:32] easy enough [14:32] pitti: yes, that's an upstream one [14:33] seb128: ah, but that's just the trigger, not the actual bug, right? [14:33] pitti: I think we should just remove the dbus service file, this way tracker is started by the session or the user or not [14:33] I don't like the "is autostarted when random program check if tracker is running" [14:33] seb128: that sounds reasonable [14:33] right [14:34] seb128: ok, let's discuss this offline [14:34] do we have someone inclined to bluetooth in the team? [14:34] ok [14:34] bug 220269 [14:34] Launchpad bug 220269 in bluez-utils "bluetooth mouse stopped working after bluez-utils and bluetooth update [hardy]" [Medium,Confirmed] https://launchpad.net/bugs/220269 [14:34] I would say to ask the mobile team [14:35] ok, I'll do that [14:35] or mithrandir [14:36] mvo: bug 221920 looks like a simple blacklist addition to compiz [14:36] Launchpad bug 221920 in xserver-xorg-video-intel "Compositing results in garbage on the screen for Intel 82815, shouldn't be turn on by default" [Unknown,Confirmed] https://launchpad.net/bugs/221920 [14:36] pitti: yes [14:36] seb128: yes, I mean 'ask the mobile team/Tollef' [14:36] mvo: can I hand that to you? [14:36] sure [14:37] bug 211388 [14:37] Launchpad bug 211388 in ntp "/etc/dhcp3/dhclient-enter-hooks.d/ntpdate not created on dapper->hardy upgrade" [Undecided,New] https://launchpad.net/bugs/211388 [14:38] that sounds pittiish [14:38] ;-) [14:38] (unless someone jumps at it :) ) [14:38] heh, I reported it [14:38] fallout from the /etc diff trawling [14:39] mvo: btw, any chance we could have an updated /etc/ diff for dapper->hardy current? [14:39] mvo: we fixed some issues in the last weeks [14:39] bug 209520 [14:39] Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] https://launchpad.net/bugs/209520 [14:39] argh the suck argh [14:39] that sounds like gvfs fallout [14:40] pitti: yes, I worked on the code to remove some noise and plan to rerun it soonish [14:40] ACTION: mvo to produce an up to date dapper -> hardy-proposed /etc/ upgrade diff [14:40] pitti: that's part of the giant gvfs smb mess we have [14:40] * pitti hugs mvo, thanks [14:41] and the bug title is not accurate [14:41] seb128: who's on that? Steve and you, I suppose? [14:41] yes, for some value of being on it [14:41] seb128: btw, it seems that SMB connection icons on your desktop disappear on upgrade; is that already known as well? [14:41] but I really need to look at those for 8.04.1 and steve offer to help on those too [14:41] pitti: it's in the milestone list somewhere, search for gnomevfs there [14:42] or gnome-vfs [14:42] seb128: ah, thanks [14:43] hm, bug 186049 [14:43] Launchpad bug 186049 in galago-sharp "System.DllNotFoundException: libgalago" [Undecided,Confirmed] https://launchpad.net/bugs/186049 [14:43] beagle search? galago? that doesn't sound very mainish to me? [14:43] no it's not [14:44] ok, so let's not worry about assigning it now [14:44] that's the list for our team as far as I can see [14:44] anything else? [14:45] not from me [14:45] nope [14:45] I'll take the task of finding/fixing some more /etc upgrade bugs [14:45] mvo already has his hands full, according to the milestone list [14:45] pitti: I'll probably have a load of main inclusion reports [14:45] needed for kde 4 [14:46] Riddell: ah, for intrepid? [14:46] pitti: yes [14:46] just to warn you (or doko) [14:46] Riddell: will intrepid drop kde3? [14:46] pitti: as much as possible yes [14:46] Riddell: right, I'm all for a package review, but we usually don't do MIRs for version upgrades? [14:46] (which, in a way, that is) [14:46] Riddell: warn about what? [14:46] pitti: right but there's new dependencies [14:47] e. g. I did not submit MIRs for a new postgresql release either, etc. [14:47] Riddell: ah; those should have MIR bugs, yes [14:47] pitti: and some new kde modules, which may or may not count as new packages [14:47] but I don't think that we need an MIR for e. g. kdelibs -> kdelibs-kde4 [14:48] doko: that I'll need various MIRs for kde 4 [14:48] Riddell: sure; let's not waste our time with busywork for the standard components which had a KDE 3 counterpart, and the rest gets MIR bugs; do you think that's reasonable? [14:48] * mvo_ is sorry - disconnected [14:48] ... so that we can hand off the remaining 3242 bugs to mvo [14:48] mvo_: oh, welcome back! [14:48] ;-) [14:48] pitti: yes, although it's not always clear what had a kde 3 counterpart [14:48] e.g. the new kdepim server [14:49] Riddell: well, common sense, I think [14:49] yep [14:49] Riddell: if you introduce new networking libraries or ffmpeg, we better MIR them :) [14:49] good, anything else we should talk about? [14:50] pitti: any news about fixing the retracers? [14:50] ugh, that [14:50] pitti: we could use debug stacktraces for some crashers [14:50] and autoduplicates closing too [14:50] ok, so tomorrow will probably keep me busy with my archive day and SRU [14:51] I'll try to reproduce these problems with fakechroot on my box this afternoon [14:51] I have no idea why it suddenly falled apart so badly :( [14:51] s/falled/fell/ [14:52] ACTION: pitti to look into fakechroot problems for apport retracers [14:52] AOB? [14:53] ok, then let's all give seb128 a big hug to spend his free day with us [14:53] and enjoy having an ice cream now! [14:54] pitti: thanks very much! [14:54] ice cream yeah ;-) [14:54] Riddell: hm, speaking about it, surprisingly few KDE bugs on the milestone list; does it just work? :-) [14:54] ah, hi Keybuk [14:54] pitti: all the code is there for hardy CDs to be enabled; somebody just needs to start running and testing them [14:55] DIST=hardy cron.daily-live etc. [14:55] cjwatson: oh, yay; they'll automatically use -proposed? [14:55] "automatically" in the sense that I've already told them to do so, yes :-) [14:55] right, that's what I meant cjwatson-proactive-automatically [14:55] cjwatson: awesome, thanks! [14:55] I'll set up the cronjobs then [14:56] thanks everyone! [14:56] pitti: well KDE 3.5 is pretty stable after three releases [14:56] Riddell: lucky you! :) [14:57] Riddell: kde 3.5.10 should *so much* be ported to gvfs *duck* [14:57] thought of the day ... [14:57] did we decide whether to do Kubuntu 8.04.1 or not? [14:57] oh, is that decision our's? [14:57] do we _want_ to? [14:57] Riddell: ? [14:57] marilize was asking me about that (by implication); I dodged the question because I wasn't sure :-) [14:58] I think what I said was that I saw no reason not to release CDs for anything that gets suitably tested [14:58] my feeling, too ^ [14:58] Keybuk: I don't think it's been discussed [14:58] Riddell: do you think it's a good idea? [14:58] there will probably be changes that affect Kubuntu, even if there's little in the way of specific work on KDE [14:58] Riddell: do you think we'll get enough test coverage for it? [14:58] i.e. kernel and platform changes [14:58] s/probably/definitely/ [14:59] kubuntu people will get the large -updates collection the first time they install updates anyway [14:59] Keybuk: yes I think we can get test coverage, it seems like a good idea to me [14:59] * cjwatson would rather take the opportunity to reduce mirror load, personally [14:59] by shipping roll-ups of updates [15:00] just the Kubuntu CD? [15:00] or the KDE 4 remix as well? [15:01] there's not been any kde 4 updates (unless we move 4.0.4 to -updates) [15:01] Riddell: same comment re kernel+platform changes [15:01] yep [15:02] so if we can get it tested, may as well [15:04] Riddell: ok, so I'll set up daily CDs for kubuntu and k4buntu, too? [15:04] pitti: please do [15:11] k4buntu> :-) === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 09 May 04:00 UTC: MOTU | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team | 21 May 06:00 UTC: Platform Team === thekorn_ is now known as thekorn === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 08 May 20:00 UTC: Ubuntu Security Team meeting | 09 May 04:00 UTC: MOTU | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team === phanatic_ is now known as phanatic === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Ubuntu Security Team meeting | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 09 May 04:00 UTC: MOTU | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team [21:01] #startmeeting [21:01] err [21:01] no mootbot? [21:01] well, I can paste logs manually. :) [21:01] heh [21:02] so, who all is here for the security team meeting? [21:02] heyya ;o] [21:02] I am [21:02] o/ [21:02] alright, let's get started. Current Agenda is here: [21:03] https://wiki.ubuntu.com/SecurityTeam/Meeting [21:03] I don't see emgent, so I'll dropped the whitehat topic for now. [21:03] [topic] CVE review [21:04] we've got a bunch of things cooking [21:04] any CVEs anyone is interested in working on? [21:05] I might suggest https://bugs.launchpad.net/ubuntu/+source/speex/+bug/218652 [21:05] Launchpad bug 218652 in xine-lib "CVE-2008-1686: Multiple speex implementations insufficient boundary checks" [Undecided,In progress] [21:05] I am handling xine-lib, gstreamer, speex and vorbis-tools, but there are a lot of universe packages that need it [21:06] yeah, it's a pretty long list. [21:06] it's an easy patch [21:06] but a lot of packages [21:07] also on the horizon is a kernel update, probably early next week. it's being built currently. [21:07] in an effort to increase CVE visibility, jdstrand and I have built a web area that is exported regularly from the ubuntu-cve-tracker bzr tree: [21:07] http://people.ubuntu.com/~ubuntu-security/cve/open.html [21:08] kees: do you want to advertise that link, since it's a symlink? [21:08] (and some graphs as well: http://people.ubuntu.com/~ubuntu-security/cve/open-cves.png) [21:08] (I don't care, but I thought since it isn't official yet, we could use the real one) [21:09] jdstrand: an index.html needs to be built up, but it's a reasonable starting point for the moment. [21:09] fair enough [21:09] it looks good so far [21:10] any help with open CVEs (especially testing) is, of course, greatly appreciated. :) [21:10] absolutely! [21:11] :) [21:11] okay, moving on... [21:11] [topic] SELinux status [21:12] propagandist: how goes selinux in the final hardy release? I haven't seen many complaints. [21:12] kees: other than a few bugs, its going well [21:13] is there any way to see how many people have switched over to it? [21:13] That would be interesting to know... [21:14] popularity-contest could give a relative idea [21:14] but I don't know how many people use that [21:14] http://popcon.ubuntu.com/ [21:14] I'm not sure how to examine just hardy, though [21:16] 42 people are using it says popcon. :) [21:16] so, I suspect that's not a useful number. [21:16] that's pretty good for how new it is [21:16] propagandist: any specific plans for intrepid? [21:17] kees: some additional policies for maybe apache and xguest (just suggestions) and some work to sync up with debian as much as possible [21:18] propagandist: sounds good. [21:18] I'm open to suggestions as well [21:18] propagandist: I'm surious as to what you'll come up with to contain apache, especially wrt virtual hosts, php and perl [21:18] s/surious/curious/ [21:19] kees: sorry, missed the roll call, belated, "here" [21:19] propagandist: btw, is anyone from tresys coming to UDS? [21:19] heya kirkland, no worries. :) [21:19] jdstrand: ;o] me too... I'll be using the current refpol as a starting point, but after that we'll see [21:19] jdstrand: I'll try to keep everyone updated on the plan for that [21:20] kees: I don't think so. It's in Prague yes? [21:20] propagandist: I mention that, because I was hoping at some point to do the equivalent with apparmor, but the way apache is packaged now doesn't really help with profiling :? [21:20] mathiaz and I started a conversation on it, but we may talk about it more at UDS [21:21] propagandist: yea, prague [21:21] propagandist: it might be a several release process to get apache in shape-- especially since we would want to get Debian involved [21:21] jdstrand: true true [21:22] okay, moving on... [21:23] [topic] hardy review [21:23] while CVEs should really cover stuff in hardy, is there anything people wanted to talk about relating to the release? [21:23] anything to do better/different for intrepid, etc? [21:23] Blog about the proactive security work [21:24] We have smack and we also have capabilities support in the kernel [21:24] Why not work on cutting down on suid root binaries? [21:24] that one can be tough because you can quickly cause usability problems [21:24] SEJeff: I've tended to blob about the things I'm directly involved in. are those other two areas ones you could blog about? [21:24] I started work on this awhile back: https://wiki.ubuntu.com/Security/Investigation/Setuid [21:25] SEJeff: it looks like a pretty short list so far, which is good. [21:25] kees, If we start writing patches to make some of those utilities only check the caps instead of the uid, would the patches get accepted into ubuntu if it takes awhile for upstream to adopt? [21:26] SEJeff: yup -- as long as there was no loss in functionality, I'd be happy to see them in Ubuntu. [21:26] SEJeff: seeing that list, cupsys shouldn't be as big of a concern-- it is protected via apparmor by default (pitti purposely dropped the extensive derooting patch IIRC because of the use of apparmor) [21:26]