[05:04] <|Giskard|> hi :)
[05:05] <|Giskard|> somebody here?
[05:05] <|Giskard|> hallo?
[07:47] <kraut> moin
[13:55] <kwwii> hi all
[13:57] <pitti> hi
[13:57] <seb128> hey pitti
[13:58] <Hobbsee> argh, it's a scary people meeting!
[13:58] <Keybuk> scary people?
[13:58]  * Hobbsee points at Keybuk. yes.
[13:58] <Hobbsee> don't you count as scary?
[13:58] <kwwii> Hobbsee: stop being sKary
[13:58]  * mvo waves
[13:59]  * Hobbsee trouts kwwii
[13:59] <kwwii> *ouch*
[13:59]  * Mithrandir gives Hobbsee some fresh salmon
[14:00] <Hobbsee> kwwii: would now be an appropriate tiem to mention that i'm not running kubuntu?
[14:00]  * Hobbsee smacks Keybuk with the salmon, then
[14:00] <kwwii> Hobbsee: don't tell me, tell Riddell
[14:00]  * seb128 hugs Hobbsee
[14:00] <Hobbsee> (thanks. that's useful)
[14:00]  * Hobbsee hugs seb128
[14:00] <seb128> ;-)
[14:00] <Mithrandir> Hobbsee: welcome to the dark^Wbrown side.
[14:00] <Hobbsee> Mithrandir: it's not brown anymore :)
[14:00] <kwwii> lol, black and orange!
[14:00] <Hobbsee> Mithrandir: bar the panels, looks remarkably like kubuntu.
[14:01] <Hobbsee> nah.  bluey-purple.  :)
[14:01] <Mithrandir> orangish, then
[14:01] <Keybuk> Riddell: ping
[14:01] <Mithrandir> kwwii: incidentially, the default openbox theme is quite a good match for our default look.
[14:02] <kwwii> Mithrandir: cool, i will check it out
[14:03] <MacSlow> Greetings everybody
[14:03] <Keybuk> Welcome back everybody
[14:03] <Keybuk> How's everyone settling back into their own timezones?
[14:03] <pitti> ~ sweet ~
[14:03]  * kwwii actually slept through the whole night
[14:04] <{ted}> Pretty good.
[14:04] <pitti> surprisingly easy, due to not being able to sleep on planes I could actually sleep Sunda ynight
[14:04] <{ted}> I had the easy one though.
[14:04] <MacSlow> Keybuk, sunday and monday felt a bit odd
[14:04]  * mvo is mostly good as well
[14:04] <Keybuk> Better than me then!  I slept most of Sunday daytime and thus am still vaguely unsure what day it is
[14:04] <MacSlow> but since tuesday everything feels solid again
[14:05] <pitti> {ted}: how have your first 'remote' days been? grinded through all the NewStaffTasks?
[14:05] <seb128> I was sleepy on sunday afternoon and I'm back on local time since monday ;-)
[14:05] <Keybuk> First thing on the agenda, Welcome Aboard to {ted}!
[14:06] <MacSlow> {ted}, official greetings!
[14:06] <{ted}> pitti: I've done a bunch of them, I need to ensure that I've done them all.
[14:06] <pitti> {ted}: can you consider using [ted] instead, for no-shift-love? :)
[14:06] <{ted}> I'm pretty thrilled that my simple package finally built.
[14:06] <mvo> {ted}: welcome!
[14:06] <{ted}> Hmm, yeah, I thought for some reason the nickserv wouldnt' let me have that one.
[14:06] <MacSlow> {ted}, took me a few days to make sure I did all needed pieces
[14:06] <seb128> {ted}: could you use a nickname without special chat at the start? it hurts my hand to use the modifier
[14:06]  * ogra would guess "ted" is taken
[14:07] <seb128> [ also needs a modifier on french layout :(
[14:07] <MacSlow> indeed... AltGr-7 is ugly
[14:07] <{ted}> Hmm, I might have to come up with something clever ;)
[14:07] <MacSlow> seb128, we should switch to US-layout
[14:07] <kwwii> he is just making sure you really want to chat with him ;-)
[14:07] <seb128> MacSlow: I like to give non-english testing to Ubuntu because we have non-english users apparently
[14:07] <MacSlow> {ted}, what about TheTed?
[14:07] <pitti> MacSlow: US layout is *so* much better for programming, vim, etc.
[14:07] <pitti> tgould?
[14:08] <MacSlow> pitti, hell yeah
[14:08] <pitti> anyway, OT for meeting
[14:08] <Keybuk> And since {ted} has joined, and is in the balmy US/Pacific timezone, this brings us onto the second agenda item ... the meeting time
[14:08] <Keybuk> thanks for all not shouting at the sudden move of an hour
[14:08] <MacSlow> Keybuk, afternoon for me so... no issues there
[14:08] <Keybuk> {ted}: are you happy with this time?  or would you prefer a little later in the day?
[14:08] <Keybuk> (obviously we now have to balance the fact the team spans nine timezones)
[14:09] <MacSlow> {ted}, must be just after getting up for you over there, right?
[14:09] <{ted}> This is good for me, it's when I normally wake up.
[14:09] <MacSlow> oh... I though all except for Ted are located in Europe
[14:09] <{ted}> It just means that i don't get to shower first.
[14:09] <{ted}> But, you guys can't smell me through IRC.
[14:09] <pitti> MacSlow: right, nothing in between the TZ span edges :)
[14:10] <pitti> {ted}: apt-get install irc-smell-plugin is not until 8.10
[14:10] <{ted}> pitti: Heh, the way things are going, I wouldn't be surprised.
[14:10] <MacSlow> pitti, some specs just should not be considered at all
[14:11] <{ted}> But, in IRC, it'll all be encoded into your nick...  just like state.
[14:11] <pitti> so, 1400 UTC then?
[14:11] <Keybuk> any objections to 1400 UTC? :p
[14:11] <MacSlow> nope
[14:11] <Hobbsee> i object!  :P
[14:11]  * Hobbsee shuts up again
[14:12] <pitti> Hobbsee: you are awake 24 hours a day, what do you care? :)
[14:12] <MacSlow> Hobbsee, can you be bribed with a cookie?
[14:12] <{ted}> nope
[14:12] <Hobbsee> pitti: not quite :)
[14:12] <Hobbsee> MacSlow: depends how much chocolate it contains.
[14:12] <Keybuk> mvo, kwwii, Riddell?
[14:12] <MacSlow> hm... 34%
[14:12] <pitti> (OT: these American cookies were sooooo yummy)
[14:12] <mvo> that is fine with me
[14:12]  * MacSlow misses the muffins
[14:12] <ogra> s/yummy/heavy/
[14:13] <Keybuk> ok, next agenda item
[14:13] <Keybuk> Spec Approval
[14:13]  * MacSlow is still working on them
[14:13] <pitti> when can a spec go from review to pendingreview?
[14:13] <pitti> erm, pendingapproval?
[14:13] <pitti> when we got one or two positive feedbacks from our fellows?
[14:13] <Keybuk> pitti: in theory, when a "reviewer" reads it
[14:14] <Keybuk> in practice, I'll read anything >= review
[14:14] <Keybuk> spec approval basically involves nagging me all of next week to read your specs
[14:14] <pitti> after Sevilla we used peer review for that
[14:14] <Keybuk> please feel free to message me on IRC with a list of those you want me to read
[14:14] <Keybuk> and keep on doing it until I do it :)
[14:14] <pitti> which worked very well IME
[14:14] <MacSlow> Keybuk, I thought we still have time  until 22nd to bring them into shape before review/approval
[14:14] <Keybuk> that's another good option
[14:14] <Keybuk> MacSlow: indeed, which is Thursday next week
[14:15] <pitti> especially feedback from upstream is helpful
[14:15] <MacSlow> Keybuk, I should have done them before the weekend
[14:15] <Keybuk> in practice, if you're mostly at review by Thursday, I'll be more than happy
[14:15] <pitti> MacSlow: NB, bring to state review != get them approved
[14:15] <MacSlow> Keybuk, the gdm dude, Jon, is pretty fast with replies... David Reveman is certainly slower with replies
[14:16] <MacSlow> pitti, indeed... I was oversimplifiying
[14:16] <MacSlow> the process
[14:16] <Keybuk> please don't let me block you - nag and shout at me if you need me to review something
[14:17] <{ted}> MacSlow: Did you ask the GDM guy about some of the power management stuff we were talking about with the logout?  Not sure that it's going to be Hardy, but I was curious what he's thinking there.
[14:17] <MacSlow> {ted}, not yet
[14:17] <MacSlow> but on my list
[14:17] <Keybuk> does anyone have any questions about the spec process?
[14:18] <pitti> I would like to defer filling out the release notes part until a beta is available
[14:18] <MacSlow> I am a bit unsure about the difference between "Design" and "Implementation"
[14:18] <Keybuk> MacSlow: sometimes it's often the same bit
[14:18] <MacSlow> ok
[14:19] <pitti> ^ I usually describe the high-level "what?" bits in design, and the actual implementation details ("how?") in implementation
[14:19] <pitti> but often, the implementation is clear from reading the design, so I think it can sometimes be skipped
[14:19] <MacSlow> pitti, changing that a bit as things go on is possible I would guess... as long as only one part "Release Notes" changes, or?
[14:20] <Keybuk> specs can change as much as you like ;)
[14:20] <Keybuk> cjwatson is a great fan of rewriting a spec after implementation so that it actually matches
[14:20] <MacSlow> well :)
[14:20] <Keybuk> since it can then serve as documentation
[14:20] <MacSlow> ah... ok... I'll remember that one
[14:21] <Keybuk> ok
[14:21] <Keybuk> pitti: PolicyKit adoption strategy?
[14:21] <pitti> right; I'm a bit nervous about this
[14:21] <Riddell> MacSlow: often my specs don't have a design at all (since if it's a port from ubuntu it has already been designed)
[14:21] <pitti> since it's basically an on/off thing (main or not at all)
[14:22] <pitti> so my current gut feeling is to do enable it in hal and put it into main, but not necessarily use it for all the things in the admin menu
[14:22] <MacSlow> Riddell, you're lucky then
[14:22] <pitti> but only for some small applications and new usage cases like g-p-m and network-manager access control for the current console, etc.
[14:23] <pitti> for hardy I'd like to keep using gksu for gnome-system-tools, for example
[14:23] <Keybuk> that sounds very reasonable
[14:23] <pitti> at least until we disable ptrace() by default in the kernel
[14:23] <seb128> I discussed that with pitti during allhand and I'm happy with doing it this way
[14:23] <pitti> it's not so much my inconfidence in the PK implementation itself
[14:24] <pitti> but more the fact that then all the admin UI will run with just user privileges
[14:24] <mvo> what about the package tools (synaptic and friends)?
[14:24] <pitti> and thus there is no security boundary any more to other user processes
[14:24] <pitti> mvo: same argument
[14:24] <mvo> gksu then
[14:24] <Keybuk> what's the ptrace issue?
[14:24] <pitti> I wouldn't like firefox plugins to install packages without notice
[14:24] <mvo> we have no tools that install without a question
[14:25] <pitti> Keybuk: e. g. if a firefox plugin ptraces users-admin or the synaptic frontend, it can use the PK privileges granted to users-admin
[14:25] <pitti> if those programs run as root, user processes can't ptrace them
[14:25] <pitti> I'm aware that you can still use Xevent injection, etc., but it's much harder
[14:25] <Keybuk> because it can steal the PK auth token?
[14:25] <pitti> whereas attaching gdb and calling system() is a trivial exploit
[14:25] <pitti> Keybuk: no, not steal
[14:26] <pitti> Keybuk: just execute arbitrary code in the process context of the target app
[14:26] <Keybuk> ahh
[14:26] <Keybuk> what did davidz have to say about that?
[14:26] <pitti> that's why I prefer having admin GUIs run as root
[14:26] <pitti> (a common misconception is that this is a bad thing per se)
[14:26] <pitti> Keybuk: it just came to my mind after we met, unfortunately
[14:26] <pitti> I'll ask him via email, but I had to catch up with too much so far
[14:26] <Keybuk> it'd be worth getting some thoughts on that
[14:27] <Riddell> pitti: doesn't policykit have a way to restrict which apps can run something?
[14:27] <pitti> so I think that using PK for things that already run as user, like g-p-m or the netapplet tool, PK is great
[14:27] <pitti> Riddell: sure it has, it assigns privileges based on process ID and executable path
[14:27] <pitti> Riddell: the point is, with ptrace() that does not help you *at all*
[14:27] <pitti> Kees and I talked about this, and he also would like to disable ptrace() by default
[14:28] <pitti> that's a slight inconvenience for developers, since they have to enable it to use gdb, strace, etc.
[14:28] <Keybuk> sadly I'm not helping that battle
[14:28] <pitti> but it's well worth it, IMHO
[14:28] <Keybuk> since Upstart *uses* ptrace
[14:28] <pitti> Keybuk: upstart == root, isn't it?
[14:28] <Keybuk> right
[14:28] <pitti> (it should only be disabled for normal users)
[14:28] <Keybuk> certainly user ptrace should be off by default
[14:28] <pitti> no reason to disable it for root
[14:28] <Keybuk> there should be a "I'm a developer" switch that enables ptrace and disables apport :)
[14:29] <pitti> something like that, yeah
[14:29] <seb128> and change the yelp icon to a gnome-terminal one
[14:29] <Keybuk> seb128: ?
[14:29] <mvo> devel mode
[14:29] <seb128> Keybuk: the icons you have on the default panel, I expect developer to want a command line rather than yelp there
[14:30] <pitti> once we have that, I'm fine with using PK for everything, since then it is equivalent protection like our current gksu (which is also susceptible to X event injection)
[14:30] <pitti> seb128: heh :)
[14:30] <pitti> so, any objection to this approach? we'll get PK for things that make good use of it, but continue to use gksudo for the main set of admin GUIs
[14:30] <Keybuk> seb128: if only yelp did devhelp stuff ;)
[14:30] <Keybuk> (one of my private annoyances)
[14:31]  * seb128 hugs pitti, looks a good approc
[14:31] <Keybuk> pitti: what kind of timeline can we disable ptrace for users?
[14:31] <pitti> then we can at least drop libpam-foreground and the nasty hacks in g-v-m, g-p-m, nm-applet, etc. to only work on the currently active session
[14:31] <Keybuk> pitti: absolutely no objection; it's better than pam-foreground so should immediately replace that
[14:31] <pitti> Keybuk: I don't know
[14:31]  * pitti makes a note to mail kernel team and Kees
[14:31] <pitti> the more interesting question is probably how to enable it again
[14:31] <pitti> disabling it is probably trivial
[14:32] <pitti> it would become a sysctl, but that might not be the most obvious interface
[14:32] <pitti> so we need to build something on top of it
[14:32] <pitti> (maybe patch strace and gdb to give an explanation?)
[14:32] <Keybuk> echo 1 > /proc/sys/kernel/root-me-root-me-root-me
[14:33] <Keybuk> ptrace has a CAP now, doesn't it?
[14:33] <pitti> "please uncomment kernel.user_ptrace in /etc/sysctl.conf" or so
[14:33] <pitti> Keybuk: I think it always had it
[14:33] <pitti> CAP_SYS_PTRACE
[14:33] <pitti> oh, sorry
[14:33] <pitti> that's only to trace processes which do not belong to you
[14:35] <pitti> a sysctl and useful explanation errors in strace and gdb seems like a reasonable start?
[14:35] <Keybuk> yup, very
[14:35] <Keybuk>         if (((current->uid != task->euid) ||
[14:35] <Keybuk>              (current->uid != task->suid) ||
[14:35] <Keybuk>              (current->uid != task->uid) ||
[14:35] <Keybuk>              (current->gid != task->egid) ||
[14:35] <Keybuk>              (current->gid != task->sgid) ||
[14:35] <Keybuk>              (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE))
[14:35] <Keybuk>                 return -EPERM;
[14:35] <pitti> ACTION: pitti to mail kees and kernel team about disabling ptrace and re-enabling interface
[14:35] <pitti> (argh, I can't do that, can I)
[14:35] <Keybuk> can't do which?
[14:36] <Keybuk> oh, I gave up with mootbot after about the second meeting
[14:36]  * pitti adds it to his personal TODO list
[14:36] <seb128> pitti: is there any bot set for the meeting?
[14:36] <pitti> Keybuk: ACTION:
[14:36] <pitti> nevermind
[14:36] <Keybuk> the fact only the chair can do actions means I have to see, copy and paste them anyway
[14:36] <Keybuk> so s/mootbot/tomboy/ :)
[14:36] <siretart> sounds easy to fix, though
[14:36] <pitti> so, I'm done with the topic, unless someone else has questions?
[14:37] <Keybuk> ok, next topic then
[14:37] <Keybuk> Patches
[14:37] <Keybuk> send your patches upstream and to Debian whenever you can
[14:37] <Keybuk> :-)
[14:37] <pitti> ++
[14:37] <Keybuk> jcastro can help you find your upstream, and find out from them how they want patches delivered and at what threshold
[14:38] <Keybuk> (this is going to be the topic of the next six months)
[14:38] <Keybuk> {ted}: well done for stepping up to deal with g-p-m so quickly!
[14:38] <pitti> now, at merge time, this is an excellent time to do so, when we clean up our patches and adopt them to the current version
[14:38] <Keybuk> exactly
[14:38] <seb128> we will start using tags for desktop packages soon, I just need to mail the list to settle the tags list etc
[14:38] <Keybuk> this is something we're not terrible at anyway; but we can always be brilliant
[14:38] <seb128> like adding bugzilla and launchpad bug numbers and a description in the patches
[14:39] <MacSlow> Keybuk, I will see to get as much as possible from my gutsy-work to Vincent
[14:39] <{ted}> tags?
[14:39] <seb128> and we will not accepted easily patches which are not sent upstream first
[14:39] <pitti> seb128: ah, I thought you meant https://wiki.ubuntu.com/Bugs/Debian/Usertagging
[14:39] <seb128> {ted}: comments on the top of the patch
[14:39] <MacSlow> Keybuk, I talked with Vincent already at UDS and know how he expects the stuff
[14:39] <seb128> pitti: what we discussed in Sevilla
[14:39] <pitti> Fedora's policy is that they do not apply and upload a patch before it is reported upstream
[14:40] <pitti> quite rigid, but effective apparently
[14:40] <seb128> they don't respect it apparently
[14:40] <Keybuk> pitti: Fedora are upstream for almost everything in their distirbution
[14:40] <Keybuk> and the things that they aren't, they certainly bloody well don't do that
[14:40] <seb128> because I browse their viewcvs quite often and they do have some patches which are not upstream there
[14:40] <Keybuk> look at the number of patches to things like sysvinit which they have
[14:40] <Keybuk> (Debian is upstream for sysvinit)
[14:40] <pitti> well, that's what Lennart told me anyway
[14:40] <pitti> (and he does)
[14:41] <seb128> we will try to do the same for desktop packages
[14:41] <pitti> anyway, I just think it's an idea to be considered
[14:41] <seb128> would probably be nice to not limit to desktop but I can't speak for other teams ;-)
[14:41] <Keybuk> amusingly
[14:41] <Keybuk> Fedora has patches in their RPMs for packages that they are upstream for
[14:41] <jcastro> seb128: do you have it written down someplace what the desktop patch policy for gnome will be?
[14:41] <pitti> heh
[14:42] <pitti> "Bow to seb128, buy him a beer, give him a hug"
[14:42] <seb128> jcastro: no, as said I need to mail the list, it's on my TODO for this week to discuss it, then I'll write it on the wiki and let you know
[14:42] <Keybuk> but our goal here isn't to pick fault in other distributions ability to send patches back
[14:42] <Keybuk> but to make sure nobody can pick fault with us :)
[14:42] <Keybuk> I already think we do a better job than anybody else
[14:42]  * mvo is very happy about this policy!
[14:42] <Keybuk> but we can always do better
[14:42] <seb128> Keybuk: depending of the "we"
[14:43] <seb128> I think it's less than optimal in MOTU land
[14:43] <pitti> *nod*
[14:43] <Keybuk> that's possibly true
[14:43] <pitti> this should probably be incorporated into the MOTU training process
[14:43] <seb128> anyway that's OT for this meeting probably
[14:43] <Keybuk> that's the end of my list of topics
[14:43] <Keybuk> any other business?
[14:44] <Hobbsee> pitti: it already is, community side.
[14:44] <pitti> Hobbsee: it hasn't always been that way, though
[14:44] <pitti> but good to know that it is like that now
[14:45] <Hobbsee> pitti: has been emphasised in the las tcouple of releases, but perhaps not enough, making it mandatory, etc.
[14:45] <Riddell> have we considered asking QA for help with New queue and archive admin?
[14:46]  * MacSlow forgot lunch today
[14:46] <Riddell> since New queue is essentially QA
[14:46] <seb128> it should not be
[14:46] <seb128> what is uploaded should have been QA reviewed first
[14:46] <dholbach> we have a lot of MOTUs feeding back patches and in sponsoring bugs it is requested a lot, though the degree of feeding of course back varies
[14:47] <Riddell> seb128: what should it be then?
[14:47] <pitti> isn't that a classic archive-admin task?
[14:47] <Hobbsee>  Riddell motu's, etc, should be doing the job of qa
[14:47] <Hobbsee> as in, checking it.
[14:47] <Riddell> the emphasis is different from revu et al, but it's essentially just another check
[14:48] <Hobbsee> there shouldnt *be* anything in that queue that isnt fine to upload.  although i'm aware that it's not the case.
[14:48] <pitti> Hobbsee: it's not that bad, though
[14:48] <seb128> well, I would not trust all the QA people to accept packages in the archive
[14:48] <pitti> most rejections are due to licensing issues, not due to bad packaging
[14:48] <pitti> (IME anyway)
[14:48] <Keybuk> (no other business? => end of meeting, to let you continue the discussion)
[14:48] <seb128> Keybuk: thanks
[14:48] <pitti> thanks everyone
[14:48] <Keybuk> if you haven't already done so, make sure you get your performance review feedback in by tomorrow (for canonical staff except MacSlow and {ted})
[14:49] <mvo> thanks
[14:49] <Hobbsee> pitti: true, but motu's should be doing licencing too, no?
[14:49] <Riddell> seb128: indeed, I'd be unsure if there's enough packaging experience
[14:49] <pitti> Hobbsee: they should, yes
[14:49]  * Hobbsee should be in bed.  night all.
[14:49] <seb128> Riddell: not only packaging, I'm not sure QA people know or care about licenses
[14:50] <seb128> Hobbsee: 'night
[14:50] <Riddell> I include caring about licence in packaging expertese :)
[14:50] <pitti> Riddell: btw, seb128 and I thought a "do three source NEWs a day" approach for the three of us would work; WDYT?
[14:50] <seb128> pitti: works for me
[14:50] <pitti> (until the current backlog is finished)
[14:50] <seb128> should we claim the packages we review somewhere?
[14:50] <pitti> then, with so many archive days we shouldn't get a big backlog anytime soon
[14:51] <Riddell> that would take about 6 weeks to clear the backlog
[14:51] <pitti> Riddell: no, it's only 30ish Ubuntu source NEWs
[14:51] <seb128> Riddell: there is not so many source NEW, that should rather be a week
[14:51] <Riddell> right, does seem like a good idea
[14:51] <MacSlow> he's taking the shower now I bet
[14:52] <pitti> ok, seems we are done; thanks again everyone
[14:52] <seb128> thanks pitti
[14:53]  * MacSlow goes for late lunch now