[01:31] <teward> anyone know how I can make my local sbuild on 14.04 recognize 'wily' as a distro for mk-sbuild ?
[01:33] <TheMuso> teward: Do you have a wily chroot set up and defined in schroot.conf?
[01:34] <TheMuso> teward: Oh wait, you mean the mksbuild command from ubuntu-dev-tools.
[01:34] <TheMuso> teward: debootstrap needs to be updated to know about wily.
[01:35] <TheMuso> apt-cache policy libgtk3.0-0
[01:35] <TheMuso> whoops
[04:24] <pitti> Good morning
[04:24] <sarnold> morning pitti
[04:24] <pitti> utlemming: sorry, I don't know; question for infinity or cjwatson perhaps?
[04:29] <Unit193> Howdy, sarnold.
[04:30] <sarnold> hey Unit193
[04:31] <sarnold> pitti: I got to wondering, how many packages did you guys wind up systemdifying before the vivid release? I suspect I'm not the only one who'd be interested in a breakdown of main / universe, how many needed systemd service files, sysv-init files, how many were sent up to debian, etc..
[04:34] <pitti> sarnold: for some rough numbers we can compare http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-13.txt to http://people.canonical.com/~jhunt/systemd/packages-to-convert/2015-04-20.txt
[04:35] <pitti> the script changed a bit in between
[04:36] <pitti> ah, so let's start with http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-20.txt
[04:36] <sarnold> pitti: is that really 191-5 == 186 packages from main and 962-6 == 956 packages from universe???
[04:36] <pitti> sarnold: so, ~ 46 packages from main, ~63 from universe
[04:37] <sarnold> aha :)
[04:37] <sarnold> pitti: still, that's amazing.
[04:37] <pitti> sarnold: I'd say I personally fixed maybe 10 universe packages, most of them came through debian I think
[04:37] <sarnold> that's a lot of packages, hehe
[04:37] <pitti> sarnold: main was mostly on our table though, as we had a lot of upstart-only packages there
[04:38] <pitti> sarnold: heh yes, I've been busy :) and thanks again to didrocks, he also helped with this
[04:39] <sarnold> pitti: impressive :) thanks for humouring my curiosity :)
[04:40] <pitti> sarnold: note, that's not accurate for any statistics (we started with the conversion way before), but the magnitude sounds about right
[04:44] <sarnold> pitti: makes sense :)
[05:01] <pitti> # apt-get install tzdata-java
[05:01] <pitti>  tzdata-java : Depends: tzdata (= 2015c-1) but 2015d-0ubuntu0.15.04 is to be installed
[05:01] <pitti> hmm
[05:01] <pitti> that causes quite some uninstallability
[05:02] <pitti> but tzdata and t-java are both built by tzdata
[05:02] <pitti> ah, that's not even just in -proposed, but in wily release too
[05:03] <pitti> infinity: ^ any idea how that made it past britney's installabilty checks?
[05:06]  * pitti syncs 2015d-1 into wily
[05:55] <pitti> ok, fixed now
[06:37] <infinity> pitti: Err, wat?
[06:37] <pitti> infinity: nevermind, all sorted out
[06:38] <pitti> infinity: tzdata was pre-installed in the VMs from vivid-updates, but vivid had a newer version than wily
[06:38] <pitti> so tzdata-java was only available for an older version
[06:38] <infinity> pitti: Ah-ha.  Yeah, I know the archive wasn't broken. :P
[06:38] <pragomer> how can I have UDF v. 2.6 support in ubuntu?
[06:38] <infinity> pitti: But this reminds me that it's probably time to turn on auto-sync.
[06:39] <pitti> infinity: yeah, let's get some new fun! wily is outright boring right now
[06:39] <infinity> pitti: Fun incoming.
[06:39] <pitti> infinity: britney etc. seems to work fine, I had quite some argument with her this morning
[06:39] <infinity> pitti: (Mostly, the reminder was you syncing one of my uploads :P)
[06:40] <pitti> infinity: yeah, that was to get four green dots back ;)
[06:40] <pitti> (libreoffice, cantor, poxml, and chromium-browser, which failed due to that uninstallability)
[06:40] <infinity> I don't know why it annoys me when people sync my Debian uploads to Ubuntu for me, but for some weird reason, it does.
[06:40] <infinity> Must some control freak issue.
[06:41] <infinity> pitti: auto-sync on.  Let's see how that goes.
[06:41] <pitti> <dholbach mode> yee-haw!
[06:41] <infinity> Oh, next run isn't until 11:00 UTC, so a bit of an anti-climax there.
[06:42] <infinity> pitti: Going back to your tzdata oops, why do your VMs have updates installed in the base at all?
[06:43] <pitti> infinity: because we have to cheat and dist-upgrade a vivid VM
[06:43] <pitti> infinity: until we get proper wily image builds (cloud images in particular)
[06:43] <infinity> pitti: Sure, I meant why do the vivid ones have updates installed.
[06:43] <pitti> why wouldn't they?
[06:43] <infinity> pitti: I guess since we only use them for SRUs, it makes sense.
[06:43] <pitti> dist-upgrade to -proposed would take ages otherwise
[06:43] <infinity> pitti: I live in a world where -security is a thing, so none of my chroots have updates in the base.
[06:44] <pitti> by pre-dist-upgrading to -updates we save the majority of per-test dist-upgrade time/work
[06:44] <infinity> pitti: Yeah, it makes perfect sense until we end up trying to use this machinery for -security, which we've never discussed, and probably don't want to do.  So, carry on.
[06:45] <infinity> I'm also less and less convinced that there  are people who run with -security-only, and I think we should revisit that some day.
[06:46] <pitti> infinity: don't we fold -updates into the next -security upload anyway?
[06:46] <infinity> The part where I didn't copy tzdata to -security until starting sometime last year but never had a single bug report about broken timezones for security-only, for instance, is a suspicious data-non-point.
[06:46] <pitti> I don't think we maintain two branches for security updates (one with pure -security, one with -updates+-security)
[06:46] <infinity> pitti: We do, but it still builds only against security and release.
[06:47] <infinity> pitti: So, for instance, a library with new symbols in -updates might have binaries in -updates that depend on it, but not in -security.
[06:48] <infinity> pitti: Anyhow, I think the separation (especially given the "base security uploads on the last SRU" policy) is probably pointless, and worth talking with Jamie's team about why we do it that way, and if we should keep doing it.
[06:48] <infinity> Hard to get good metrics about it, though.
[06:49] <infinity> The only two I have are non-data.  tzdata and linux-firmware, which are now included in security, but didn't used to be.
[06:49] <infinity> The former leading to broken timezones, the latter to completely nonfunctional kernel drivers.
[06:49] <pitti> infinity: yeah; over the years I shifted my mind to "security.u.c. is just a faster mirror" mostly
[06:49] <infinity> And no bugs about either.
[06:49] <pitti> I still remember the long debates that we had about whether or not to keep -security as a totally separate branch, and effectively applying security patches twice
[06:50] <infinity> pitti: See, if there really is a "completely stable only-security" use-case, we should have done that.
[06:50] <infinity> pitti: But we didn't.
[06:50] <infinity> pitti: And the current policy is just a bit odd.
[06:51] <infinity> It's also not uncommon for random universe packages to get security updates via SRU instead of being done through the security team.
[06:51] <infinity> Which is "wrong" in the split model, but wouldn't matter if everyone's running -updates anyway.
[06:52] <lifeless> isn't that the only way random universe packages can get security updates?
[06:52] <infinity> lifeless: No, the security team encourages people to submit MOTU security fixes to them to pass through the PPA to -security.
[06:53] <infinity> lifeless: But not everyone gets the memo, and sometimes people do micro-release SRUs that just happen to also fix 27 CVEs, etc.
[06:53] <lifeless> heh
[06:53] <lifeless> thanks
[06:54] <infinity> pitti: I think what I'd be happier with is if -security became more of an "urgent -proposed".  People have it on by default (as now), we implicitly trust the uploaders (as now), but it builds against -updates, and is just a faster way through SRU that doesn't need the usual baking period.
[06:54] <infinity> pitti: I might have a discussion with jdstrand and friends about this when they wake up.
[07:01] <tjaalton> anyone know what's different between starting suspend from the menu or hitting the hotkey? (or xdotool key XF86Sleep)
[07:01] <tjaalton> because there's a bug in trusty that only happens with the hotkey
[07:02] <mgedmin> hotkey is handled by gnome-settings-daemon; menu is handled by ... uh ... probably not gnome-shell if you use unity, but anyway
[07:02] <pitti> indicator-session ^
[07:02] <tjaalton> ok
[07:02] <pitti> they should both eventaully go through logind to actually do the suspend request, though
[07:03] <pitti> the lock screen behaviour is a bit different, though
[07:03] <seb128> the indicator locks the screen before suspending, not sure about u-s-d
[07:03] <tjaalton> it's a i915 bug, probably just a pageflip less with the menu
[07:03] <pitti> seb128: it's supposed to do the same
[07:04] <pitti> it should set a delay suspend inhibitor, lock the screen, and release the inhibit after locking
[07:04] <pitti> perhaps tjaalton can tell us what the bug actually is :)
[07:04] <seb128> yeah, that would be easier ;-)
[07:06] <tjaalton> total system hang
[07:06] <tjaalton> so, the usual deal
[07:06] <tjaalton> on haswell
[07:06] <tjaalton> it's fixed in 3.19 at least
[07:06] <tjaalton> just need a ton of bisecting..
[07:07] <pitti> tjaalton: ah, so at least you can run trusty with the lts-vivid backported kernel?
[07:07] <pitti> (do we actually have that already?)
[07:08] <seb128> bah, neeed torestart, 90% of the chars got missing fromù my screen
[07:08] <pitti> so you put in some extra chars as compensation :)
[07:08] <tjaalton> pitti: yes, but it's an oem bug
[07:08] <tjaalton> needs to be fixed in trusty kernel
[07:09] <tjaalton> lts-vivid is in proposed at least
[07:09] <tjaalton> the kernel
[07:09] <tjaalton> rest to follow once infinity allows ;)
[07:10] <seb128> http://people.canonical.com/~seb128/xchat.png
[07:11] <tjaalton> intel?
[07:11] <seb128> tjaalton, ^ do you know if that's a video issue?
[07:11] <seb128> yes, i5
[07:11] <tjaalton> more specific
[07:11] <tjaalton> every gen has i3/i5/i7 :)
[07:12] <pitti> seb128: I sometimes get something similar, but usually ctrl+L helps
[07:20] <seb128> tjaalton, ironlake gen5 from xorg log
[07:20] <tjaalton> so gen5
[07:20] <tjaalton> uh
[07:20] <tjaalton> you said that
[07:21] <seb128> pitti, ctrl-L where? when it starts doing that it's on all applications, not one
[07:21] <pitti> seb128: yes, I know, here too; I just press it (I'm usually in gnome-terminal), it helps here
[07:22] <seb128> last time I noticed it seemed font specific though, if I change the text size it's fine, if I go back to the old value it's the same issue
[07:22] <seb128> text does get redraw on focus changes sometime though
[07:24] <tjaalton> this on vivid?
[07:24] <seb128> tjaalton, yes
[07:24] <pitti> yes
[07:25] <tjaalton> check dmesg if you don't have a gpu hang
[07:25] <tjaalton> or does X restart cure it?
[07:27] <pitti> at least here it never hangs, it just disrupts the screen all of a sudden; I can work on, and redrawing screen helps
[07:28] <seb128> tjaalton, session restart fixes it
[07:28] <seb128> I just did a logout/login cycle to fix it
[07:32] <tjaalton> k
[07:32] <tjaalton> if you can build -intel from git that would be something to try
[07:34] <seb128> tjaalton, well, it's not like the issue was easy to reproduce
[07:35] <seb128> it's also not new from vivid, I have it happening sometimes for some cycles
[07:36] <tjaalton> ok
[07:38] <seb128> but would that be a video driver issue?
[07:38] <seb128> not sure how font rendering works exactly
[07:39] <tjaalton> it's sna acceleration bug I think
[07:39] <tjaalton> you can switch to uxa in xorg.conf too
[07:39] <tjaalton> to see if it ever happens again
[07:40] <seb128> tjaalton, looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=88584
[07:41] <tjaalton> yeah
[07:43] <seb128> pitti, ^
[07:45] <pitti> ah, thanks
[08:04] <LocutusOfBorg1> hi doko_ are you sure you fixed the kfreebsd-amd64 build failure? I see 5.1.1-4 still failing... thanks
[09:33] <rbasak> $ pull-lp-source -d hello wily
[09:33] <rbasak> pull-lp-source: Downloading hello version wily
[09:33] <rbasak> pull-lp-source: Error: Failed to download: https://launchpad.net/ubuntu/+archive/primary/+files/hello_wily.dsc: 404 Not Found
[09:34] <rbasak> Is that expected?
[09:34] <rbasak> I haven't updated distro-info-data or anything so it is out of date.
[09:34] <rbasak> But I still expected an explicit "wily" to work. "vivid" does.
[09:37] <cjwatson> Noskcaj: edit-acl -p noskcaj query (from bzr lp:ubuntu-archive-tools)
[09:38] <cjwatson> utlemming: they're in lp:~ubuntu-cdimage/debian-cd/ubuntu
[09:39] <cjwatson> rbasak: Yes, it looks like pull-lp-source decides whether the argument is a series name or a version number by checking whether it's present in distro-info-data
[09:39] <rbasak> cjwatson: ah, that makes sense, thanks. I'll update distro-info-data.
[09:40] <Laney> rbasak: tumbleweed said he was going to do it
[09:40] <cjwatson> rbasak: it's already done somewhere
[09:40] <rbasak> Oh. I meant locally. I assumed it was already updated in the archive.
[09:40] <cjwatson> Right
[09:41] <Laney> Don't see it in unapproved at any rate
[10:14] <LocutusOfBorg1> 45 minutes to the sync? :)
[10:20] <cjwatson> LocutusOfBorg1: Takes it a while to think about it before it starts copying
[10:58] <doko> LocutusOfBorg1, why is kfreebsd relevant here?
[11:02] <LocutusOfBorg1> I don't see you in the debian-devel channel :)
[11:07] <jpds> stgraber: Can you take a look at https://bugs.launchpad.net/ifupdown/+bug/1452238 ?
[11:08] <ricotz> doko, hi, is there an official backport of gcc for precise planned to deal with applications dropping support for gcc < 4.7
[11:15] <rbasak> jpds: that looks likely to be an issue with sysvinit, not ifupdown. Why was initscripts not configured on your system? Had it previously failed to configure?
[11:15] <jpds> rbasak: It was a brand new box.
[11:15] <rbasak> jpds: how was it installed?
[11:15] <jpds> rbasak: I'd literally never touched it before.
[11:15] <jpds> rbasak: Came per-installed.
[11:17] <rbasak> jpds: I'm interested to know whether "apt-get -f install" complains about anything before attempting the upgrade.
[11:17] <jpds> rbasak: It doesn't, it fixes the issue.
[11:18] <rbasak> jpds: it doesn't complain? Or it does and fixes the issue? And this is all before update/upgrade, right?
[11:18] <jpds> rbasak: Put the output in the bug.
[11:18] <rbasak> jpds: OK, but did you run this after or before the upgrade attempt?
[11:19] <jpds> rbasak: After.
[11:19] <jpds> rbasak: Then it does its thing, and one can dist-upgrade again.
[11:19] <rbasak> jpds: what does "dpkg -l initscripts" give you, please?
[11:20] <jpds> rbasak: Don't have access to my machine right now.
[11:23] <jpds> rbasak: http://cdimage.ubuntu.com/ubuntu/releases/14.04/release/ubuntu-14.04-server-amd64+mac.list
[11:24] <rbasak> jpds: I wanted to know configuration status of that package before and after the upgrade failure.
[11:25] <rbasak> jpds: the full log of the upgrade would be helpful too. I wonder if it's a dependency loop. It needs a deeper dive than I have time for right now, sorry. Maybe stgraber will know faster. Some kind of dependency loop maybe?
[11:53] <pragomer> hi. I have no dns in my remastered live-iso (that works perfect except of dns). as I see via google this is not only my problem. but I could not find a solution. could you help me?
[12:21] <cjwatson> auto-sync properly underway now
[12:45] <LocutusOfBorg1> cjwatson, I see ghc building on wily right now, didn't you mention a blacklist for haskell?
[12:46] <cjwatson> LocutusOfBorg1: most of the rest is blacklisted until ghc itself builds
[12:46] <cjwatson> LocutusOfBorg1: blacklisting ghc would not help that cause :-)
[12:47] <LocutusOfBorg1> I though the blacklisting was until the debian transition was done :)
[12:47] <cjwatson> No
[12:47] <LocutusOfBorg1> I mean, you were waiting for the haskell stuff to migrate to testing ;)
[12:47] <cjwatson> It's because I don't want us to have to build haskell-* out of order only to have to build it all again in order
[12:47] <cjwatson> No, that would take ages
[12:48] <cjwatson> This is purely a let's-get-the-ordering-right thing
[12:49] <cjwatson> (auto-sync has copied everything now)
[13:38] <seb128> jibel, pitti, hum
[13:38] <seb128> "wily-adt-samba - Build # 1 - Failure:
[13:38] <seb128> Public Jenkins URL:  https://jenkins.qa.ubuntu.com/job/wily-adt-samba/1 to view the results."
[13:38] <seb128> but that url is a 404?
[13:39] <pitti> it ran here: http://d-jenkins.ubuntu-ci:8080/job/wily-adt-samba/?
[13:40] <seb128> need vpn access to see that one
[13:40] <pitti> seb128: jibel sent an RT to create the /Wily view on public jenkins; no idea whether that also needs action to copy the actual jobs
[13:40] <jibel> seb128, given the number of job running the publisher is probably late
[13:40] <pitti> hm, some do exist: https://jenkins.qa.ubuntu.com/search/?q=wily-adt
[13:41] <seb128> jibel, shouldn't the emails be sent after the publishing when the log has there?
[13:41] <jibel> seb128, this job finished less than 10 minutes ago
[13:41] <pitti> so I guess it just takes time to catch up
[13:41] <seb128> has->is
[13:41] <pitti> seb128: maybe, but we don't control the public jenkins
[13:41] <jibel> seb128, no that's completely differnet
[13:41] <seb128> bah, and why can't I access d-jenkins even if with the vpn
[13:41] <pitti> well, what we "should" do is to get rid of jenkins :)
[13:41] <seb128> oh, works now
[13:42] <seb128> go figure
[13:42] <jibel> seb128, the sync to the public instance can take several minutes up to several *long* minutes if there are big attachments
[13:42] <seb128> jibel, pitti, thanks
[13:43] <seb128> seems like  python-samba is not installable
[13:44] <seb128> shrug, and of course activating the vpn makes everything else timeout/stop working, I had forgotten about that
[13:45] <pitti> seb128: how do you mean?
[13:45] <pitti> seb128: I have the VPN on all the time (auto-started for me on boot)
[13:45] <pitti> it's not supposed to hang anything else
[13:45] <pitti> s/boot/connecting to my home network/, but all the same
[13:45] <seb128> pitti, dunno if I misconfigured the vpn in nm-connection-editor, but when I activate it from there the non-vpn web stops working for me
[13:46] <pitti> seb128: does your default route go via VPN now? that would explain it
[13:46] <pitti> $ ip route|grep default
[13:46] <jibel> seb128, don't use the vpn as your default route
[13:47] <pitti> seb128: in NM, select the VPN -> Ipv4 settings -> Routes... [X] Only use for resources of this network
[13:47] <pitti> seb128: it should be on by default; switching it off will use it for default route, which doesn't work for me either
[13:48] <seb128> pitti, thanks, that's checked
[13:49] <seb128> in fact this time it didn't make the interweb stop working
[13:49] <seb128> but some IRC networks and thunderbird timeout
[13:49] <pitti> seb128: ok; default route points to your normal router, not VPN?
[13:49] <seb128> so it's like it was making something that open connections don't like
[13:49] <seb128> pitti, correct
[13:49] <pitti> seb128: ah, the internal irc probably?
[13:49] <seb128> yes
[13:49] <seb128> and the canonical imap
[13:49] <pitti> seb128: ok, that sounds plausible
[13:49] <seb128> so maybe just canonical machines
[13:57] <Saviq> mhall119, mzanetti, elopio_, just watching "Unity8 User Documentation", not sure if you got to that conclusion, but I totally agree with the goal of automating that
[13:57] <Saviq> the documentation text itself should totally live next to the test itself
[13:57] <mhall119> Saviq: the conclusion was that we should build a prototype covering one specific thing, and see how it goes
[13:58] <mzanetti> Saviq, yeah, mhall119 will come up with a prototype
[13:58] <mzanetti> Saviq, so you met elopio's bird :D
[13:58] <Saviq> one thing I wanted to mention is: if any of the full-stack test fails, it needs to be looked at anyway
[13:59] <Saviq> it's either that the test is not stable, wrong, or something really needs to change
[13:59] <mzanetti> yeah. it definitely sounds like it could work out
[14:01] <Saviq> mhall119, long-term we could think of a way for the doc team to get a set of diffs (text and visual) between published and current state to go through and ack/nack
[14:01] <mhall119> Saviq: diffs to the docs?
[14:01] <Saviq> mhall119, yes
[14:01] <Saviq> the docs could be generated daily/per-image, depending on how often the full-stack testing runs
[14:01] <mhall119> Saviq: I was hoping the docs team would help you guys update them directly
[14:02] <mhall119> in the bzr branch
[14:02] <Saviq> mhall119, sure, but then, before publishing them
[14:02] <Saviq> mhall119, you likely want a sanity pass
[14:02] <Saviq> over the changes
[14:03] <Saviq> mhall119, then, a few times in a cycle, we could generate them for different locales, and even for different devices...
[14:03] <mhall119> Saviq: true
[14:06] <Saviq> elopio_, mhall119, FWIW I don't think we need that many screenshots (11 for unity7 were mentioned? ;)), it's probably whoever writes the initial doc should leave a hint in the text where a screenshot is needed
[14:07] <mhall119> Saviq: for Unity, yes, but if this works we can have it over individual apps too
[14:08] <elopio_>  Saviq, mzanetti, mhall119: it's also worth thinking about videos.
[14:08] <Saviq> mhall119, totally
[14:09] <Saviq> elopio_, and yeah, totally
[14:10] <Saviq> elopio_, it'd likely be useful to also be able to only take a screenshot of a certain region (launcher.screenshot())
[14:11] <Saviq> but yeah, one step at a time :)
[14:15] <mhall119> elopio_: for videos, having touch-event overlays would really be useful
[14:15] <mhall119> touch/mouse
[14:25] <Riddell> uos question: how do I get the hangout url for a session I'm running?
[14:29] <seb128> Riddell, copy paste from your url bar
[14:30] <seb128> ctrl-L + ctrl-C + ctrl-V in most browser
[14:30] <Laney> https://wiki.ubuntu.com/UDS/Sessions shows how to do all the mangling
[14:31] <Riddell> ah that's the URL I want thanks Laney, the summit site only links to some out of date docs
[14:35] <mitya57> ScottK: does it make sense to copy qscintilla2 from vivid-proposed to wily, or you are going to fix it via Debian soon?
[14:35] <ScottK> I think it will get auto-copied, but in any case I plan an upload in Debian soonish, so I think it's not worth expending effort on.
[14:37] <mitya57> Ok
[15:07] <xnox> doko: will you be at the GCC5 update session?
[15:08] <xnox> doko: in one hour
[15:09] <doko> maybe ;)
[15:09] <xnox> doko: hehe
[17:44] <tumbleweed> Laney: yeah, sorry. Couldn't do it at the time, beacues it wasn't open yet. And couldn't later because I didn't have key material with me. Then it fell off my stack
[17:46] <hjd> Anyone know when http://qa.ubuntuwire.com/ftbfs/ will switch to show status for wily?
[17:47] <tumbleweed> hjd: wgrant runs that
[18:11] <smoser> arges, https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1272414
[18:11] <smoser> the fix there...
[18:11] <smoser> do you have to configure sudo somehow to get it ?
[18:12] <arges> smoser: what do you jmean?
[18:12] <smoser> the upstream discussion talkss about a sudo config iption
[18:12] <smoser> option
[18:12] <smoser> er... maybe it doesnt
[18:13] <smoser> oh. the bug summary does
[18:13] <arges> smoser: you have to add a special flag
[18:13] <smoser> it says "the ability to disable th echecking the network intefaces with a runtime option"
[18:13] <arges> --probe-interfaces
[18:13] <smoser> so its fast *unless* you run sudo with that ?
[18:13] <arges> err the config is 'Set probe_interfaces false' (sorry its been a while since I looked at this)
[18:15] <arges> smoser: http://www.sudo.ws/repos/sudo/rev/e9dc28c7db60  seach for the man page description
[18:15] <arges> so in systems with lots of virtual interfaces (neutron routers for example) sudo is really slow since its scanning all those veth pairs
[18:17] <smoser> arges, yeah. thats what i'm seeing.
[23:20] <bdmurray> mdeslaur: Are the upstart tasks in bug 1391296 still necessary?
[23:32] <mdeslaur> bdmurray: no
[23:32] <mdeslaur> uh, wait a sec
[23:32] <mdeslaur> bdmurray: no, closing them now
[23:33] <bdmurray> mdeslaur: thanks