{{{ 09:02 mdz Keybuk said he probably wouldn't be able to make it 09:03 mdz and I expect the same for sabdfl as he's travelling 09:03 ogra Seveas, obviously self chosen 09:04 mdz I think we can call this a quorum though 09:04 mdz there is one candidate for the core development team, Sebastian Drge 09:04 mjg59 Shall we get on with things, then? 09:04 mdz is that slomo? 09:04 dholbach slomo, are you there? 09:05 dholbach mdz: yes 09:05 mdz launchpad says yes 09:05 ogra yup, thats slomo === janimo [n=jani@Home03207.cluj.astral.ro] has joined #ubuntu-meeting === slomo_ [n=slomo@ubuntu/member/slomo] has joined #ubuntu-meeting 09:05 mdz slomo_: hello 09:05 mdz we were just looking for you 09:05 slomo_ hi everybody, hi mdz :) 09:06 slomo_ mdz: yes, ogra told me... sorry 09:07 mdz slomo_: you mention on your wiki page that you maintain a package in Debian; are you a DD or do you have a sponsor? 09:07 slomo_ mdz: currently i only have some sponsors but i want to apply for NM in some months/weeks 09:08 mdz slomo_: who are your sponsors? 09:08 slomo_ mdz: dajobe, ajmitch and lool 09:08 mdz are any of them present? 09:09 mdz maybe ajmitch, I'd like to hear from him 09:09 sistpoty ajmitch said he'd be on his way to work 10mins ago 09:09 slomo_ he left only some minutes ago afaik :/ and the others are not present 09:09 mjg59 slomo_: Your wiki page lists a couple of packages that are also in Debian (the musepack ones, from a quick search) - what the situation there? 09:10 mdz slomo_: do you have any specific plans which require upload privileges for main? mjg59: i definitly have to update my wiki page ;) the xmms-musepack was 09:10 slomo_ uploaded by someone else some weeks ago... but i plan to get my bmp-musepack package in when i find a sponsor with some time... the other's are ubuntu only atm and i've itps for them 09:11 mjg59 slomo_: Ok, cool mdz: i want to work mostly on mono specific packages, helping ajmitch and 09:11 slomo_ tseng... but if some help is needed elsewhere i'm happy to help out wherever i could be useful 09:11 ogra mdz, we could drop xine on him ;) 09:11 ogra slomo does a lot with multimedia packages === Burgwork [n=corey@S010600131016cf6f.gv.shawcable.net] has joined #ubuntu-meeting 09:12 \sh slomo is a tough guy for the hard nuts ... MOTU owe him a few 09:12 mdz slomo_: which packages, and what sort of work? 09:13 ajmitch_ morning 09:13 slomo_ mdz: for mono? the complete mono stack from ground up... i.e. cli-common, mono, gtk#, monodoc, etc === ajmitch_ didn't realise there was a TB meeting today, sorry :) === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-meeting 09:15 ogra Keybuk!! 09:15 mdz slomo_: what would you like to change about those packages presently? 09:16 mdz Keybuk: (slomo, [11]https://launchpad.net/people/slomo applying for ubuntu-core-dev) mdz: get the latest stuff in, get everything working fine together and we 09:16 slomo_ plan to get some more mono specific packages like gtk#2 for example to main for dapper 09:17 ajmitch_ mdz: what would you like to ask about the sponsored packages or other work? 09:17 mdz slomo_: what is needed in order to get everything working well together? 09:17 mdz ajmitch_: yes, feel free 09:18 ajmitch_ ok, slomo has done most of the mono work for dapper that was required for merging debian changes === vincent_ [n=vincent@85.69.101.91] has joined #ubuntu-meeting 09:18 ajmitch_ he's worked well with the debian mono team to get issues sorted out 09:19 ajmitch_ and the packages I've had time to sponsor have been very clean, with few things to fix up or clarify 09:19 ajmitch_ I'd like to see him able to upload the mono stuff directly to main, especially as we get more of it in 09:20 mdz ajmitch_: thanks mdz: slomo_ works on gst-plugins-multiverse, he seems to be good job to 09:20 seb128 coordinate with the main package and work with the Debian maintainer on changes too 09:20 seb128 s/seems// 09:20 mdz seb128: that's great ,thanks 09:20 seb128 s/seems to be/do/ 09:20 ogra and slomo mainly maintains mplayer nowadays 09:21 ogra and ffmpeg etc ... 09:21 mdz slomo_: are you still there? mdz: mostly dependencies between those packages... they're very closely 09:21 slomo_ tied. or for example when when updated to mono 1.1.9 some packages broke because of stricter compiler so these needed to be fixed too 09:21 mdz slomo_: what can we do to make that situation better? 09:22 slomo_ mdz: sure, i needed to sort my thoughts a bit... i wasn't really prepared for this right now ;) i didn't know there was a meeting 09:22 mdz slomo_: if you would prefer to wait until the next meeting, that's no problem 09:22 slomo_ mdz: mostly work with upstream to get everything in a stable state 09:23 mdz slomo_: I'm looking for specific and concrete actions that you would like to take in main, as examples of what we could expect from you 09:23 ajmitch_ upstream being debian or real upstream of the programs that break? mdz: ok... well, you could expect from me that i get the latest versions in 09:24 slomo_ until UVF, trying to keep breakages at the lowest level possible and get some more mono specific packages from universe to main and caring for them there 09:25 mdz slomo_: how would this relate to the work that tseng is currently doing on mono? 09:26 slomo_ mdz: i would do exactly the same stuff he does... we would share the work between us to get more work done in shorter time 09:27 slomo_ ajmitch_: both mdz: also ogra's idea about working on multimedia packages appeals to me... 09:27 slomo_ for example i maybe could help seb128 with the transition to gst 0.10 later if he wants it... so if there is some work to be done in this area i would gladly help out 09:28 mdz slomo_: have you seen [12]https://launchpad.net/distros/ubuntu/+spec/video-playback ? 09:28 mdz I would like to hear your ideas about how we could provide the best unencumbered video playback capability in the default install mdz: not yet, but i know that problem but haven't thought about a 09:29 slomo_ appropriate solution for it yet... but a/v sync problems should become better with gst 0.10 afaik 09:30 seb128 slomo_: are you interested by splitting xine for this? :) slomo_: We don't have a terribly good reputation as a multimedia 09:31 mjg59 distribution at the moment. Given the constraints we have (patents, free software) how do you see us changing that? 09:31 slomo_ seb128: why not? but what exactly needs to be split off? well, let's talk about this later 09:31 mdz slomo_: he's talking about the video-playback spec I referred to earlier slomo_: do you have some ideas for any feature goals you would be 09:32 mdz interested in working on during the Dapper cycle, either something already in the spec tracker or an idea of your own? slomo_: the "Split xine such that only the Xiph codecs (and perhaps 09:32 seb128 additional, unencumbered ones) are supported in main, the others will be shipped in universe" of the spec mjg59: in regards to patents we currently support the most formats we are 09:33 slomo_ allowed to... improving on them would imho be the only way to get better. and these are most problems i heard people had with ubuntu.... i.e. they can't play their dvds out of the box 09:33 mjg59 slomo_: Do you think we can do a better job of making it clear why they can't? 09:33 slomo_ mdz: mostly the avahi goal but this is obviously completly unrelated to everything i talked about yet 09:34 slomo_ seb128: sure, i could try splitting it that way 09:34 seb128 would be nice :) 09:34 seb128 thanks! 09:34 slomo_ mjg59: only by writing more documentation... i see no other way. but currently the wiki already includes all this informations so no idea :/ slomo_: At the moment, I think we're integrating the technical side of 09:35 mjg59 multimedia into the distribution fairly well, but the social side is less clear mjg59: yes but except doing more documentation, maybe writing a "multimedia 09:36 slomo_ guide" or something similar i see no way to let the people know why we can't support for example dvd playback out of the box 09:37 mjg59 It would be good to think about ways we can improve that in the distribution, rather than just referring people to the wiki 09:37 Burgwork totem/rb needs to be able to tell people what specific codec they need 09:37 mjg59 The totem user experience in Ubuntu is currently fairly dire slomo_: on your wiki page you mention that you find FreeBSD to be a 09:37 mdz superior server platform. can you elaborate on this, and suggest specific improvements which could make Ubuntu a more natural choice for servers? and for general improving of playback of all kinds of formats i think we 09:38 slomo_ should try to get more tests done... some of the issues which showed up after release like the dvd playback problem caused by gst-ffmpeg would be detected much earlier and could be tried to fix 09:38 slomo_ mjg59: yes, i know nobody who uses totem atm because it's too unstable for them :( that needs to be improved somehow 09:39 mdz I use totem and have not found it unstable 09:40 Burgwork slomo, is that something we can push on to the laptop testing team? They already have the hardware === gauss [n=enrico@gailleton-2-82-67-8-40.fbx.proxad.net] has joined #ubuntu-meeting mdz: i think ubuntu is on the best way to be better on the server side. i started using freebsd on servers already some time ago and the biggest 09:40 slomo_ advantage i saw was that you had a main system which is perfectly integerated and almost bug free... but imho the same already applies to ubuntu now... in fact i'm already using ubuntu on one server now 09:41 slomo_ mdz: it's mostly the applet or when playing wmv/quicktime... for "normal" formats it works well... normal beeing xvid, theora, vorbis, etc 09:42 mdz slomo_: what do you think we could do to better test multimedia support as you propose? mdz: get a bunch of people who regurlary test popular and unpopular 09:44 slomo_ formats... and report their problems ;) maybe make a list of formats we can play and check if it works regularly === doko_ [n=doko@dslb-084-059-099-238.pools.arcor-ip.net] has joined #ubuntu-meeting 09:45 ogra slomo_, volunteering to make a testplan ? ;) 09:45 dholbach ogra: add it to: [13]https://wiki.ubuntu.com/TestPlans :) 09:45 ogra hehe 09:46 ogra dholbach, only if he says he does ;) 09:46 slomo_ ogra: sure... i think i can try to get something reasonable done soon :) 09:46 ajmitch_ ogra: why? just volunteer him for it 09:47 ogra ajmitch_, i'm the evil recruiter, but not *that* evil :) slomo_: what I would suggest is to extend 09:47 mdz [14]https://launchpad.net/distros/ubuntu/+spec/test-plans to include a simple multimedia test in the test plan 09:47 ajmitch_ ogra: go on, take the next step ;) 09:47 mdz slomo_: perhaps you could work with dholbach on this 09:47 dholbach i'm happy to 09:48 slomo_ mdz: sure... sounds good :) slomo_: and also to help with 09:48 mdz [15]https://launchpad.net/distros/ubuntu/+spec/example-content to ensure that we have a good test video stream in the default install to facilitate that 09:48 mdz mjg59: do you have any further questions you'd like to ask? 09:48 mdz if not, I'm ready to call a vote 09:49 mjg59 I think I'm done 09:50 mdz ok, votes? 09:50 ogra +1 (if i could) 09:50 mdz ogra: please leave the voting to the board 09:51 mjg59 I think +1, based on the discussion of a testing regime and thinking about improving the entire user experience 09:51 mdz +1 from me based on positive feedback from the development team and the potential for solid contributions to main === dholbach hugs slomo 09:52 mdz slomo_: congratulations, thanks and welcome === ogra applauds === slomo_ hugs dholbach :) 09:52 ajmitch_ well done slomo_ 09:52 slomo_ thanks everybody :) 09:52 dholbach EXCELLENT === pitti ^5 slomo, welcome to the main team! 09:52 seb128 slomo_: congrats === \sh hugs slomo and congrats him :) 09:52 seb128 slomo_: I'll ping you for gst0.10 so :) 09:52 \sh I read correctly: only two votes? was it the first time that a main dev had only two votes? 09:52 mdz \sh: no, we have many times had 2/3 votes 09:52 dholbach slomo_: now if i might invite you to #ubuntu-desktop, we have some things to discuss ... :-p (seb: we have him) 09:53 mdz but today we have only 2/4 present and 2/2 votes 09:53 \sh mdz: oh ok :) 09:53 sistpoty congrats slomo 09:53 \sh dholbach: don't take him away from the motu... 09:53 mdz janimo: you proposed yourself for core-dev during the meeting; did you intend to apply during this meeting or for the next one? 09:53 slomo_ dholbach: sure, but i don't have that much time today anymore ;) need to do some university stuff now... only made a break for the meeting now ;) 09:53 slomo_ \sh: don't worry :) 09:53 janimo mdz, no hurry, as long as xfce is still in universe 09:53 janimo next time is fine 09:54 mdz janimo: since we've been here an hour already and have more agenda already, if you don't mind waiting, I think that would be better 09:54 janimo ok, np 09:54 mdz we seem to have 3 new MOTU candidates since the last meeting 09:55 dholbach mako :) 09:55 mdz zakame doesn't seem to be here 09:55 mdz mako: ping 09:55 mdz bojan doesn't seem to be here 09:55 ajmitch_ sadly, since zakame has been doing a fair bit of work lately with merges 09:55 \sh hmmm... 09:55 mdz mjg59: I'm comfortable considering mako in absentia if you are, since we know him quite well already 09:56 dholbach what happened to bmonty? 09:56 \sh bmonty can't be here again.....but I would like to propose a vote in absentia 09:56 mjg59 Yup 09:56 \sh because bmonty did now a great work during the merge etc. and I really like to see him in the team. 09:56 mdz +1 from me for mako, no-brainer based on past contributions to both Debian and Ubuntu 09:56 mjg59 +1 for mako, too 09:57 mdz done and done 09:57 ajmitch_ that was a quick appointment :) 09:57 \sh mako: do some merges asap :) 09:57 Seveas wow, fastest ever I guess :) 09:57 ogra yes, bmonty was postponed several times ... 09:57 dholbach \sh: i watched his work too, and i was impressed, by how much bmonty did during those merges === tseng [n=tseng@li2-186.members.linode.com] has joined #ubuntu-meeting 09:58 mdz mako has been contributing to Ubuntu since its inception and has only now decided to apply officially ;-) 09:58 \sh dholbach: yes .. I did some uploads for him the last days...and I'm impressed 09:58 ogra and prepares uploads all the time for us ... its a bit sad 09:59 sistpoty yes... the few packages of bmonty i came to look over showed good packageing skills. and he did _lots_ of work 09:59 slomo_ bmonty would also get a vote by me... he does _SO_ many merges lately we almost can't keep up with uploading his stuff 10:00 sistpoty and he interacts with debian (files bug w. patches in BTS for stuff he changes) 10:00 mdz is he mostly doing trivial merges from MOM or more in-depth merging as well? 10:01 \sh mdz: both 10:02 mdz ok 10:02 \sh mdz: most of universe is trivial only one out of 50 is really non trivial 10:02 \sh (forgetting the gstreamer universe packages of slomo) 10:03 mdz mjg59: any questions regarding bmonty? === sistpoty counts 24 dapper changes mails from bmonty 10:03 \sh sistpoty: and some syncs he couldn't request 10:03 mjg59 mdz: Don't think so - motu reports sound good 10:04 mdz yes, while he isn't present there are several people here willing to provide testimonials 10:04 \sh sistpoty: and not all of his reports are uploaded actually 10:04 mdz votes? 10:04 ogra he was really patient with being postponed from meeting to meeting ... 10:04 mjg59 +1 from me 10:04 mdz +1 from me based on testimonials from several regular MOTU contributors and reviewers, both at this meeting and previous ones 10:04 dholbach cool :) 10:04 ajmitch_ we'll inform him of the good news then 10:04 mdz dholbach: will you pass on the news to him personally? 10:04 sistpoty \sh: very true... we need to sponsor more uploads. I think I'll go for this tonight... -> motu after meeting 10:04 ogra welcome bmonty in absentia ! 10:05 dholbach mdz: i will 10:05 \sh mjg59 / mdz: thanks :) 10:05 mdz dholbach: thanks, send my congratulations 10:05 dholbach mdz: as personally, as internet lets me :) 10:05 \sh dholbach: blog it :) 10:05 dholbach we don't have a MOTUPhoneNumber page yet :) 10:05 \sh dholbach: I know he is reading the planet :) 10:05 \sh +49 700 sourcecode? ,-) 10:05 mdz there are 18 pending applications in launchpad right now 10:05 Seveas Dial M for MOTU ;) 10:06 \sh or should I get +49 700 motu ? 10:06 mdz ogra,dholbach: would you ping each of them and confirm that they still intend to apply and will attend a meeting? we need to clean out that list 10:06 ogra mdz, 90% of them i've never heard of 10:06 dholbach mdz: i know 3 of those missing ones 10:06 ogra or seen them on irc 10:06 dholbach mdz: that's sivang, vuntz and zakame 10:06 mdz if you've never heard of them, they should receive a form letter explaining how the process works 10:06 pitti btw, what about cleaning up members which are inactive? like astaroth? 10:07 ogra most of them dont even have a wikipage 10:07 dholbach mdz: i will take care of that 10:07 mdz dholbach: thank you very much 10:07 dholbach de rien 10:07 ajmitch_ pitti: I think maintainership was meant to have a year or 2 year term, right? 10:07 pitti ajmitch_: ah, ok 10:07 mdz pitti: what is astaroth's real name? 10:07 pitti mdz: Gerardo di Giacomo 10:08 pitti mdz: the guy who helped with universe security updates until he became a MOTU 10:08 pitti it's by no way urgent to remove him, this example just came into my mind 10:08 mdz pitti: please ping him and see if he intends to contribute in the future 10:08 pitti yes, will do 10:08 dholbach same for some other folks 10:08 mdz pitti: we should not generally deactivate anyone simply because they go inactive; we have the expiration process for that === zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-meeting 10:09 zakame hi all 10:09 ajmitch_ hi zakame 10:09 \sh dholbach: we should discuss how we should proceed with this "problem" \sh: it's hard to decide... pinging back is the only thing, i can think of 10:09 dholbach - there are times in life, where you simply don't have the time or drive to do it \sh: a reasonable approach is to contact them and ask their intentions. if 10:09 mdz they say that they can't or won't contribute anymore, they can voluntarily deactivate themselves in launchpad 10:10 mdz \sh: and if they don't respond, they will eventually expire 10:10 \sh mdz: ok..so the expiration process is already working :) 10:10 mdz zakame: just in time 10:10 zakame mdz: thank you :) 10:11 ajmitch_ mdz: will we have to undergo another interrogation around expiry time? :) 10:11 mdz dholbach: you mentioned that you had some experience working with zakame? 10:12 mdz ajmitch_: we have some time to finalize that part of the process ;-) 10:12 ogra zakame, nice wikipage :) 10:12 zakame ogra: many thanks :) 10:12 dholbach mdz: that i "knew him" and watched his progress - he's been fairly busy in the mergers crew and iirc did some std allocator changes as well 10:13 dholbach mdz: i have 217 bug mails from him, mostly merges, some bug triaging work as well 10:13 zakame just a couple for c2a i think... libcommoncpp2 was already done in debian, and my most recent one was for MAS 10:14 dholbach i'm not too familiar with his work, but what he said in #ubuntu-motu usually was sound 10:15 ogra zakame, you dont mention that you help in edubuntu too on your wiki .... 10:15 sistpoty though I haven't reviewed much of his work, I'm impressed by zakame's amount of work... 10:15 \sh oh yes..zakame is just hard working like bmonty or ajmitch, slomo, siretart, sistpoty or my person. zakame: I happened to notice your merge of lostirc; it looks like the only 10:15 mdz Ubuntu-specific change had been to update to a new upstream version, which is now in Debian. why was this a merge rather than a sync? 10:15 \sh I had a view over his work, and his debdiffs were very good, for the time he's doing motu work. I'm happy to have him in the team 10:17 zakame mdz: hm, you're right, this seems to just update aclocal.m4, and yes, S-V :( my bad! 10:17 \sh mdz: beginners luck I would name it...because I'm the one who has "beginners luck" all the time...;) 10:18 zakame ogra: Ooh! I forgot that part! very sorry!!! 10:18 ogra mdz, zakame expressed interest to help in edubuntu ... 10:18 mdz zakame: please be careful with that in the future; each package which is diverged creates more work for the team 10:19 ogra zakame, was it doc or dev ? 10:19 zakame mdz: yes, I'll keep that in mind 10:21 mdz zakame: who sponsors your uploads to Ubuntu usually? ogra: hm, I'm collaborating with some teachers at the local school to 10:23 zakame implement an edubuntu system... we currently are running hoary, but I managed to get hold of edubuntu yesterday, so we'll be trying to upgrade maybe this afternoon 10:23 ogra cool 10:24 \sh mdz: nafallo and I 10:24 zakame mdz: Nafallo_away did most of the sponsoring, though most recently \sh sponsored logilab-common and another... zakame: we'll take a look for the others...actually I was busy merging 10:25 \sh during the weekend...so I have to find the time to get all pending uploads done from malone 10:25 mdz mjg59: anything else before voting? 10:25 mjg59 Don't tihnk so 10:25 zakame \sh: thanks again :) most of them are PendingSync 10:25 mdz likewise 10:26 mdz +1 based on my own examination of various uploads, testimonials from MOTU and discussion 10:26 \sh zakame: if you can provide me a list of malone numbers :) that would be great :) 10:26 mjg59 +1 based on the MOTU opinions 10:26 ogra \sh, see wikipage :) 10:26 mdz zakame: welcome aboard === dholbach hugs zakame 10:26 dholbach that's brilliant news :) 10:26 sistpoty congrats zakame 10:26 ogra yay, welcome zakame 10:26 minghua zakame: congratulations. :-) 10:26 \sh zakame: welcome aboard :) good shot :) 10:26 slomo_ zakame: congrats :) 10:27 mdz pitti: you wanted to discuss something regarding sudo? 10:27 pitti right 10:27 ajmitch_ zakame: well done 10:27 zakame yay! === zakame hugs everybody :D 10:27 pitti [16]http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013260.html 10:27 pitti ^ for reference 10:27 zakame many thanks all! :) 10:27 pitti there was not much fruitful discussion 10:27 mdz right, this thread is long and I haven't had a chance to read it yet 10:27 pitti the problem is in short: 10:28 pitti initially we wanted to use sudo -t command to check whether an user can execute command 10:28 \sh zakame: cool page :) I'll work with the information from this page 10:28 zakame \sh: thanks 10:28 pitti if that would log auth failures, then it would remain compatible with default sudo behaviour on servers and not circumvent security checks 10:28 mdz pitti: I think extending sudo to parse the .desktop file adds undesirable complexity to a setuid root program 10:29 pitti mdz: I only see two options TBH: parse .desktop files in sudo or fall back to the broken group check 10:29 pitti mdz: parsing .desktop files would nicely solve the desktop/server conflict 10:29 pitti on servers there won't be .desktop files, so that sudo checks are not impeded 10:29 pitti and on desktops we would avoid the log clutter from failed checks 10:30 mdz pitti: it would certainly be nice to avoid execing sudo so many times during every login 10:30 pitti mdz: well, we need to execute it once for every desktop file that wants root 10:30 mjg59 pitti: The sudo -t case would presumably also result in error mails every time someone logs in? 10:30 pitti i. e. maybe 15 times for a normal system per login 10:30 ogra how would that cope with the gnome speeup plans ? 10:30 ogra *speedup 10:30 pitti mjg59: right, that's the most annoying thing right now 10:31 mjg59 Why are we trying to achieve this? 10:31 mdz mjg59: in order to simplify the menus for unprivileged users 10:31 pitti mjg59: we want to hide admin tools from the menu for users who aren't admins 10:31 mdz i.e., don't show them administrative tools requiring sudo if they won't be able to use them 10:31 pitti [17]https://wiki.ubuntu.com/HideAdminToolsToUsers 10:31 mjg59 Surely a common use case is that an admin will wish to debug things while a user is logged in? 10:31 mdz mjg59: the menu items have no chance of working unless the user has sudo rights 10:31 Mithrandir pitti: can't we write a helper which is suid root and parses the desktop files and asks sudo "can this user run this command"? 10:31 mjg59 Hrm. True. 10:31 pitti mjg59: 'run program as another user' 10:32 ogra and the worst thing is that they just silently fail 10:32 pitti Mithrandir: what would that solve? 10:32 pitti Mithrandir: sudo would still log violations 10:32 Mithrandir pitti: it would not put the desktop parsing code in sudo. 10:32 pitti Mithrandir: and doing the check in sudo is safer than writing a new program from scratch 10:32 mjg59 ogra: I think the silent failure is a bug in itself, but still... 10:32 ogra yup 10:32 mdz Mithrandir: that code would still run as root, though 10:32 Mithrandir mdz: yes, but it would be easier to merge from debian that way. 10:33 pitti I mean, parsing is not terribly difficult 10:33 pitti but of course it must be done carefully 10:33 mjg59 But surely this inevitably subverts part of sudo's security? 10:33 Mithrandir pitti: I just don't see upstream wanting to incorporate that patch, without knowing sudo upstream. 10:33 mdz pitti: is there a program which is run whenever a new .desktop file is instaled? 10:33 pitti mjg59: to the extent that an intruder can check commands mentioned in installed (root owned) desktop files pitti: one approach would be to have such a program dump a list of all of 10:33 mdz the relevant commands to a (trusted) file and have sudo suppress its error reporting for any command listed exactly in that file 10:33 pitti mjg59: but on desktops we can safely forget about logging anyway 10:34 mjg59 pitti: Which, in a standard ubuntu install, amounts to everything 10:34 pitti mdz: dpkg install hooks? (SCNR) 10:34 mvo there is dh_desktop 10:34 pitti mjg59: why everything? 10:34 pitti mjg59: on a server there won't be any/many desktop files 10:34 mjg59 pitti: If a user has sudo rights to execute admin tools, they have sudo rights to execute anything 10:34 pitti and seriously, whoever runs sudo under X doesn't need to care about the logging 10:35 pitti mjg59: under X at least (event injection, etc.) pitti: what does a hypothetical attacker gain by being able to test for 10:35 mdz sudo rights in this way? any attempt to use those rights is more closely scrutinized 10:35 pitti mjg59: but the case I worry about is to not impede server security checks To be honest, I'm fairly strongly of the opinion that we should just accept 10:35 mjg59 that we made a mistake in Warty, cut our losses and just display them for users in the admin group and otherwise not do so 10:35 mdz pitti: for the common case, any unprivileged user on the system can already check for membership in the admin group 10:35 pitti mdz: he can silently poke around to check which privileges a cracked user account has 10:36 pitti mdz: right now, sudo immediately mails out failures to the admin 10:36 mjg59 Rather than produce a complex solution that provides extra information leakage about what rights a user has 10:36 pitti mdz: so that the admin can quickly close the user account, etc. 10:36 mdz mjg59: if we do that, we need to heuristically add users to the admin group on upgrades 10:36 pitti mjg59: but that's not just a warty upgrade issue 10:36 mjg59 mdz: No, we can document it in the release notes 10:36 mdz pitti: they can already do that silently with 'groups' 10:36 pitti sudo is more flexible than just crude admin/no admin 10:36 mjg59 "Admin applications will only be visible to users in the admin group" 10:37 dholbach sorry, i'll leave now, because i'm dead tired - good night 10:37 mjg59 pitti: Yes, but it's not the sudo case that we care about really 10:37 ogra bye dholbach 10:37 mdz mjg59: we don't display the release notes on upgrades yet 10:37 zakame bye dholbach :) 10:37 pitti mjg59: well, the question is if we do... 10:37 mjg59 What we care about is "should this user see these icons" 10:37 pitti I don't see why we should force admins to use the admin group 10:37 mjg59 pitti: Because it's the existing mechanism for flagging user capabilities 10:37 mdz pitti: I don't think we should; I'm just pointing out that we already make most of this information available by using the admin group the way wedo 10:38 pitti mdz: not on my server :) I use /etc/suders to directly configure allowed commands for users, not via groups 10:38 mjg59 In the brave new world of selinux, the obvious thing to do would be to have admin users have an selinux capability 10:38 pitti mdz: I agree, when the admin group is used, the case is trivial 10:38 ajmitch_ that brave new world won't be on by default in dapper 10:38 mdz and that is our default configuration for Ubuntu 10:38 Mithrandir mjg59: what would we do in the cases of people being allowed to do some things as root, but not all? 10:39 ogra mdz, not for warty upgraded systems Limiting visiblity to people in the admin group fixes the vast majority of 10:39 mjg59 cases that we're worried about, and doesn't involve us developing what is, effectively, a new authentication mechanism 10:39 mdz ogra: that is missing the point 10:39 ogra mdz, that will be a good bunch of users .... 10:39 pitti mjg59: but that makes the usage of non-group sudo impossible 10:39 janimo checking sudo -t only once and then using a blacklist of apps which are not to be shown? would that not scale? 10:39 mjg59 pitti: No it doesn't 10:39 pitti mjg59: since then the users would never see the desktop files 10:40 mjg59 pitti: The apps can be run from a shell 10:40 mdz ogra: the only reason not to use sudo for this is that it reveals information 10:40 pitti mjg59: right, of course 10:40 pitti I mean in terms of correct menus 10:40 mjg59 pitti: They can launch a shell, add themselves to the admin group and then re-login 10:40 mdz ogra: but that is only the case if the user has extensively customized the system, since our default configuration and tools reveal it already 10:40 pitti mjg59: erm? 10:41 mdz janimo: what would the blacklist contain? === mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-meeting 10:41 pitti mjg59: if I allow an user to run only a particular command as root, he can't 10:41 pitti janimo: that doesn't react to changes 10:41 janimo the apps which are to be run only as sudo 10:41 mjg59 pitti: Are you suggesting that certain users should have access to specific admin tools, but not all? 10:41 janimo changes as in introducing new packages? 10:41 pitti janimo: we already know this, it's in the desktop files 10:41 mjg59 pitti: Making icon visibility depend on being in the admin group doesn't mean that the admin group must have full sudo rights 10:41 ogra mdz, my initail reaction was the same as yours, but Kamion made some valid points i cant remember currently ... sad he isnt here 10:41 pitti mjg59: why not? I could allow an user to set the time, but nothing else 10:42 mjg59 pitti: It's an insanely tiny use-case 10:42 pitti well, ok, if we say that we basically ignore /etc/sudoers and jsut support admin group, that's fine for me 10:42 mdz mjg59: we don't need to account for it in our defaults, but we should avoid making it impossible if w ecan 10:42 pitti I just want to have that decision formally settled 10:43 mjg59 mdz: It would still be possible by changing the semantics of the admin group on that system 10:43 mdz mjg59: how do you mean? 10:43 mjg59 mdz: Don't give admin users sudo rights 10:43 pitti mjg59: no, you need several groups then, which we don't suport 10:43 pitti mjg59: well, we could have a mapping somewhere 10:43 mjg59 pitti: We don't support it how? 10:43 pitti group -> desktop files 10:44 mdz mjg59: hmm 10:44 mjg59 I mean, you /could/ solve this just by having the desktop files be 640, right? 10:44 pitti mjg59: i. e. the menu only reflects admin membership, not the actual privileges an user ahs 10:44 pitti has, even 10:44 mjg59 Or just using ACLs 10:44 pitti mjg59: sure, but who configures that? 10:44 mjg59 pitti: The admin 10:45 pitti dpkg-statoverride? well, that would work 10:45 mjg59 I'm sorry, I feel like I must be missing something really obvious here 10:45 pitti but it certainly needs a guy 10:45 pitti gui, even 10:45 mdz mjg59: we have some conflicting goals 10:45 mdz we would like to hide the entries where the user can't possibly make use of them 10:45 pitti our current sudo supports sudo -t command 10:45 mdz but we want to avoid hiding them if the user can use them 10:45 pitti but that generates clutter on desktops 10:46 pitti so we need to test at a higher level 10:46 Mithrandir pitti: can we just get sudo -t to log, but not mail? I think that would be ok. 10:46 mjg59 mdz: But that goal inherently provides information leakage about user capabilities 10:46 mdz we implemented a solution as pitti describes which makes it trivial to query sudo for this information 10:46 pitti Mithrandir: then we don't need mail for sudo without -t either 10:46 mdz mjg59: yes, in my opinion a certain amount of leakage is probably OKO 10:46 mdz OK 10:46 pitti Mithrandir: which would change sudo semantics on servers, too 10:46 pitti Mithrandir: sudo -t command && sudo command 10:46 Mithrandir pitti: hmm, right. 10:47 mjg59 mdz: I worry about changing security expectations from traditional unix 10:47 pitti mjg59: right, the question is how much leakage we want to sacrifice for this hide-admin spec 10:47 mdz pitti: hmm? 10:47 ogra cant you add a switch to sudo for mailing the admin can set ? 10:47 mdz mjg59: I think sudo is a bit young to have traditional security expectations 10:47 ogra i.e. have it off by default on desktops and on on servers ? 10:47 mdz and this problem only applies to sudo 10:47 pitti ogra: sure, but I doubt that it would be easier than grepping desktop files 10:47 mjg59 mdz: I've seen people using it for years 10:48 pitti ogra: what defines a server then? 10:48 \sh sudo is not young..it wasn't popular...just like the story about telnet and ssh 10:48 ogra pitti, dunno, but we build this system, we can define it ... 10:48 mdz mjg59: I agree with you in that getting to dapper from warty requires fairly extensive command-line familiarity already 10:48 pitti ogra: the problem is, the admin defines the purpose of the install, not we :) 10:49 mdz mjg59: but I think we need to do better than the release notes if we're going to rely on admin membership in this way 10:49 ogra pitti, but we can define flags that get set, based on default options the installing person choose 10:49 pitti ogra: right, that was option 2 in my email to u-d 10:49 ogra or checks 10:49 mdz pitti: do you think we could safely add users to the admin group on upgrades? 10:49 mjg59 mdz: Well, it's possible to do that (at the cost of requiring manual intervention during the upgrade) 10:50 pitti mdz: no, I'd not do that 10:50 mdz the entry created in sudoers by the installer is specially marked 10:50 pitti mdz: IF the admin configured fine-grained permissions, then this would lead to privilege escalation 10:50 Mithrandir mdz: we could have an upgrade tool which asked the admin how he wanted stuff done, but I dislike that. === ajmitch_ hasn't added an admin group here, and probably would be surprised to see it on an upgrade 10:50 mdz pitti: I think that can be avoided 10:50 pitti well, I wouldn't have a good feeling with changing group memberships on upgrades, even less so with admin 10:50 \sh mdz: this is somehow not the right solution...better to ask during dist-upgrade "Who is your admin user?" 10:50 mdz pitti: the process would be to check for an entry in sudoers of the form: 10:50 Mithrandir something like a ubuntu-fixup package which asked questions and tried to fix stuff in the postinst. 10:50 mdz # Added by Ubuntu installer 10:50 mdz mdz ALL=(ALL) ALL 10:51 pitti mdz: we check for a default sudoers and do it only then? 10:51 mdz pitti: a sudoers with the default entry 10:51 mdz pitti: which is equivalent to admin group membership 10:51 mdz i.e., unrestricted sudo to root 10:51 pitti mdz: well, that would cover the warty upgrade, what about the general usage of visudo without admin group? 10:51 pitti i. e. finer grained privs? 10:51 mdz pitti: wouldn't those be superseded by the ALL entry? 10:52 mdz configuring finer-grained privileges would require removing the ALL entry 10:52 pitti mdz: I mean with nonstandard sudoers (when we don't add users to admin) 10:52 pitti not for upgrades 10:52 mdz pitti: I don't understand 10:52 pitti mdz: if I allow joe to use sudo time-admin, but nothing else, then joe would not see time-admin in the menu 10:52 pitti mdz: if we don't care about this case, then group check is sufficient 10:52 pitti if we do, then it's not 10:52 mdz pitti: unless you add joe to the admin group 10:52 mjg59 Does dpkg-statoverrides have support for POSIX ACLs? 10:53 mdz mjg59: RUN AWAY 10:53 mjg59 mdz: But then he'd see all of them, not just time 10:53 mdz mjg59: that is acceptable to me 10:53 pitti mdz: he would not be in admin, of course, otherwise the 'sudo time-admin' entry would be pointless 10:53 mdz pitti: if the admin wants finer grained permissions, they would remove the %admin entry 10:53 pitti I know that it's a corner case 10:53 \sh pitti: is this the normal use-case for desktop installations? 10:53 pitti but we should clearly say whether or not we support it 10:54 pitti \sh: no 10:54 \sh I think I can remember windows xp asking even unprivilegded users to update windows xp via windows update pitti: It's something that can be supported by the admin removing the read 10:54 mjg59 bit from the desktop files, and then adding individual users to an associated ACL 10:54 \sh and the user clicks on the toaster and "u don't have rights" 10:54 ogra \sh, remember we are better than MS 10:54 pitti mjg59: I agree 10:55 mjg59 And I think we support ACLs on all our supported filesystems 10:55 mdz mjg59: which ones are our supported filesystems? 10:55 ogra heh 10:55 pitti it's just not something a non-hardcore freak would do 10:55 mdz mjg59: currently, the process for granting admin privileges is trivial: adduser admin, or check the tick box in the GUI tool ogra: what I wanted to say with this is: what is the typical use case for a 10:55 \sh desktop...single machine. and if there is a second or third account most people don't care if they see the admin tools or not...if they get the "sorry, not allowed" message..they don't care anymore 10:55 mjg59 mdz: Right, and I'd see that as the default 10:56 mdz ACLs complicate that for both cases (more commands, and complicating the tool) 10:56 mdz mjg59: so you're suggesting that we don't try to hide these entries by default? 10:56 mjg59 No, we hide those entries by default 10:56 mdz mjg59: and leave it to the admin only if they really want to configure it that way? 10:56 pitti but isn't our problem exactly the other way round? 10:56 mdz pitti: yes 10:56 mjg59 In the corner case of an admin wanting a user to be able to run a single application but not all of them, they use the ACL solution 10:56 pitti users who aren't in admin, but have special rights won't see the desktop file 10:57 pitti instead of users without rights see them === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting 10:57 mjg59 mdz: ext3, xfs, jfs, reiserfs and nfs support them mjg59: the ACL solution being: remove the %admin entry from sudoers, add 10:57 mdz the more specific entries, and set ACLs on the .desktop files corresponding to the more specific entries? 10:57 pitti ah, I see, we make the desktop files root:admin 640 by default? 10:57 mjg59 mdz: Correct === seb128 [n=seb128@ubuntu/member/seb128] has left #ubuntu-meeting ["Ex-Chat"] 10:57 mjg59 pitti: Yeah, that would work === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting 10:58 mdz mjg59: I think dpkg probably clobbers ACLs on upgrades 10:58 mjg59 mdz: Well, that's a feature request for dpkg :) 10:58 ogra and i dont think we need even to think about this special cornercase ... 10:58 ogra switch all on or all off ... 10:58 pitti "Dear Keybuk, please teach dpkg-statoverride ACLs, kthxbye"? 10:59 mdz pitti: I have an idea 10:59 pitti give us the ultimate solution, Matt! :) 10:59 mdz pitti: we could allow users to query sudo without any logging or warning if they are in the admin group 10:59 \sh hmmm.... 10:59 mdz pitti: and otherwise, fall back to displaying all of the menu entries 10:59 pitti mdz: that's what happen right now 10:59 pitti oh, wait 11:00 ogra isnt that backwards ? 11:00 pitti well, if they are in admin, then we already know everything 11:00 mdz IFF they are in the admin group 11:00 pitti we want to know information if they aren't 11:00 ogra exactly 11:00 mdz if they aren't, we just display everything 11:00 ogra but we dont want this 11:00 mjg59 mdz: Uhm. No, surely? 11:00 pitti well, then we don't need to do anything :) 11:00 mdz I'm not particularly interested in having finer-grained menu entries corresponding to finer-grained sudoers 11:00 mdz I just don't want the functionality to disappear from the desktop undesirably 11:00 pitti becaue that would mean to always show everything :) 11:00 mjg59 mdz: If they're not in the admin group, we don't want to display anything 11:01 mdz mjg59: you are introducing facts into the discussion 11:01 ogra lol 11:01 \sh I wonder if it's possible to create a patch which is doing the query if a user is in admin group or not inside of the menu display 11:01 mjg59 Simplest solution: 11:01 mjg59 1) Make .desktop files 640 and group admin owned 11:01 pitti \sh: that's easy, yes 11:02 mjg59 2) Transition default user to admin group for warty upgrades 11:02 mjg59 Result: Most use cases sorted 11:02 mdz mjg59: 2) is scary 11:02 pitti I have a bad feeling about 2) 11:02 ogra mjg59, how do we know its a warty upgrade ? 11:02 \sh pitti: and the gnome-menu reads the desktop file, right? 11:02 pitti but I like 1) 11:02 mjg59 We're talking about users who, in sudoers, have ALL=(ALL), right? 11:02 pitti \sh: right 11:02 mdz mjg59: we don't have a persistent record of who the default user is and whether it's been customized 11:02 mjg59 So they could add themselves to the admin group *anyway* 11:02 pitti right 11:03 ogra mjg59, yes, but i might have set this in a brandnew breezy because i think its cool 11:03 mdz mjg59: it seems probable that there are corner cases 11:03 ogra so we would break hat 11:03 ogra that* 11:03 pitti I'm not questioning that, but we have to make damn sure that we get that right 11:03 mdz what happens when you have multiple matching entries in sudoers for a user? 11:03 mjg59 mdz: If they have a fine-grained setup, we do nothing pitti: so..when we set a special "X-Admin: true/false" inside of the admin 11:04 \sh apps and checking in gnome-menu if or if not the user a) is in admin group or not and b) if the app which is described in .desktop is admin tool or not..and then display or not display it 11:04 mdz mjg59: meaning what? we don't touch it unless it hasn't been modified since installation? 11:04 pitti \sh: see the spec, yes 11:04 mdz mjg59: I'm saying that I think sudoers semantics may allow a finer-grained setup without removing the default entry 11:04 mjg59 mdz: I think we can justifiably add any user who has privileges to run anything to the admin group 11:05 pitti mjg59: your chmod solution has the added benefit that we don't actually need to add that X-Requires-Root: true key :) 11:05 Mithrandir mjg59: that's not problematic, I think giving the admin group root-equivalent priviledges might be more problematic. === ogra still wonders why we solve a GUI problem in the backend, and not in the GUI 11:05 \sh ogra: you can read my mind? 11:05 mdz mjg59: I'm saying that that situation is difficult to detect reliably; it may not be as simple as looking for the expected line in sudoers 11:05 mdz mjg59: and the risks of being too liberal are pretty severe 11:05 ogra its a task for gnome-menus as it was thought out in the beginning imho 11:05 pitti ogra: how do you want to determine if user foo can execute sudo command? 11:06 ogra pitti, if i check his groups 11:06 pitti mdz: if we go for group checking, then I'd prefer a release note 11:06 \sh pitti: sudo should be excuted by anyone...the app to run afterwards is determined by sudoers...we still have the cli 11:06 mdz pitti: I fear that we will be flooded by reports of users upgrading and then being locked out 11:06 pitti not doing a relative simple .desktop parsing for security reasons, and then add a highly delicate sudoers rewriting doesn't fit together 11:06 ogra i wouldnt touch sudo at all ... 11:07 mdz pitti: we don't know how many breezy systems are out there which are upgrades from hoary and warty 11:07 mjg59 The current options have at least one of the following problems: === lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-meeting 11:07 mjg59 a) Increase information leakage 11:07 pitti ogra: well, but see backlog, not every sudoer is in admin group 11:07 mjg59 b) Increase code run as root 11:07 mjg59 c) Are awkward for upgrades 11:07 mdz we've already increased the information leakage 11:07 mjg59 mdz: How? 11:07 ogra pitti, corner cases ... 11:07 pitti with the admin group 11:08 mdz mjg59: sudo -t no longer asks for a password 11:08 mjg59 mdz: I think that's a bug 11:08 mdz mjg59: it just bitches in the log 11:08 \sh pitti: but during a dist-upgrade from warthy, hoary, breezy to dapper, we could ask questions...and we can "rearrange /etc/sudoers" 11:08 pitti mdz: how is that information disclosure? 11:08 mdz pitti: for the same reasons we've been discussing all along 11:09 ogra why not focus on the group and make a note in the release notes ... to warty systems it simply wont make a difference ... 11:09 pitti mdz: I don't understand why sudo -t command without a password discloses information 11:09 mdz pitti: it allows the user (or an attacker with their privileges) to query sudo 11:09 pitti mdz: right, but not unnoticed mdz: Unless the default behaviour of sudo -t failing is identical to the 11:09 mjg59 default behaviour of attempting to execute a command without privileges (in terms of admin notification), I think that's incorrect 11:09 mdz pitti: the information is still leaked, we just record the fact that it was leaked 11:10 mjg59 When was this -t behaviour changed? 11:10 mdz dapper 11:10 mjg59 Right. So we can revert it. === amu [i=amu@debian/developer/amu] has joined #ubuntu-meeting 11:10 mjg59 mdz: It's the sort of thing that will get mentioned on bugtraq 11:10 mdz if we can't do this without unacceptable tradeoffs in robustness or security, we should consider not doing it 11:10 mdz mjg59: I do not fear bugtraq 11:10 pitti mdz: right 11:11 mjg59 mdz: I don't fear bugtraq. I fear negative PR associated with "Ubuntu change security tool default behaviour to one that leaks more information" 11:11 mdz I believe it was also mentioned on bugtraq that we grant sudo privileges rather than using a root password 11:11 amu moin 11:11 mdz the world moved on 11:11 ajmitch_ hi amu 11:11 ogra hey amu 11:12 pitti ok, then let's ignore the custom sudoers case and just check for admin membership 11:12 ogra yeah 11:12 mdz pitti: that leaves us back to dealing with warty upgrades 11:12 pitti the workaround is really evil, but it seems that sudo solution is evil, too 11:12 ogra for warty upgraded systems the menu will just go on looking like before ... 11:12 mjg59 mdz: If sudo -t continues to log, then that's going to be a *lot* of log entries for terminal server-type installs 11:12 mdz and hoary, in fact, no? didn't we change to group admin in breezy? 11:12 mjg59 And if it doesn't log, it's a security pain 11:12 ogra i dont think thats bad 11:12 mjg59 I /think/ hoary had an admin gorup 11:12 pitti mjg59: it should log 11:13 mdz mjg59: it's unacceptable to use sudo for this if it logs 11:13 pitti mjg59: hoary had 11:13 mdz mjg59: but you've said that you find it unacceptable to use sudo for this at all, already 11:13 mdz because we can't use sudo for the query unless we allow it to be queried without a password mdz: I think it's bad to use sudo in a way that leaks information. I think 11:13 mjg59 it's /terrible/ to use sudo in a way that doesn't log if an unauthorised user runs it. I'm all for using the admin group check IFF we can find a way to fall back 11:14 mdz gracefully for systems which never had that configuration in the first place 11:14 pitti mjg59: well, with the desktop file test, we would not leak any info on servers 11:14 mdz do we create the admin group on upgrades? if not, we could check for its existence 11:15 ogra no, we dont 11:15 pitti we would drop -t 11:15 pitti and introduce --check-desktop-file, or so 11:15 mjg59 pitti: Uhm. 11:15 mjg59 pitti: How does that help? 11:15 ogra why must that be done on sudo pitti ? 11:15 ogra in* 11:15 pitti mjg59: on servers there are no .desktop files, so there is no information leak 11:15 mdz ogra: are you sure? where is admin created? 11:15 mjg59 pitti: That's not a sensible assertion 11:15 pitti ogra: /etc/sudoers is readable only by root 11:16 ogra mdz, from hoary on in the installer afaik 11:16 mjg59 pitti: mjg59@kern:~/ > locate .desktop | grep /usr | wc 353 353 16080 11:16 ogra pitti, we have the info in the .desktop files, we can make gnome-menus check the group 11:16 mjg59 mjg59@kern:~/ > wc /etc/passwd 11:16 mjg59 3576 8484 220748 /etc/passwd 11:16 ogra no need to touch sudo at all 11:16 mjg59 pitti: So, no. Being a server does not mean that people don't run graphical sessions. 11:17 pitti mjg59: well, we would limit the information leak to exactly the information we need - desktop files 11:17 pitti instead of arbitrary commands 11:17 pitti mjg59: well, if people use sudo under X, then we don't need to worry about information leaks 11:17 mjg59 pitti: But the user then (effectively) knows that they can execute whatever is in that .desktop file 11:17 mdz ogra: I can't find where it's created 11:17 pitti mjg59: exactly 11:17 pitti that's the amount of sacrifice we need to do IF we want this 11:17 ogra mdz, i only know that its there since hoary ... for all new installs i did 11:18 mjg59 pitti: Right. So I think it's a stupid idea in that form. 11:18 ogra mdz, and its not there on upgraded systems 11:18 pitti mjg59: it's better than sudo -t command IMHO === pusakat [i=proxy@203.167.88.65] has joined #ubuntu-meeting 11:18 mjg59 pitti: Being stabbed in the hand is better than being stabbed in the eye :) 11:18 sistpoty why not check in /etc/group as heuristic instead of the sudoer-file? 11:18 pitti *shrug* 11:18 mdz pitti: how about my suggestion? 11:19 pitti mdz: the one with not doing anything at all? 11:19 mdz pitti: if the admin group exists, use it to test whether to display the menu entries. if it doesn't exist, display them all. 11:19 pitti mdz: that's what we have now 11:19 ogra mdz++ 11:19 mjg59 That works for me. 11:19 pitti oh, ok 11:19 mdz pitti: and revert the sudo change 11:19 pitti mdz: would work for me 11:19 ogra the behavior for upgraded warts just wont change ... 11:19 mdz I thought we created admin on upgrades, but ogra pointed out that this isn't true 11:19 mdz so this is a very simple solution 11:19 pitti for warty upgrades that's certainly fine 11:20 pitti people are used to the menus by now, probably 11:20 mdz ok, I think we've licked it 11:21 ogra so keep the change at gui level ? 11:21 mdz that only took an hour 11:21 pitti mdz: that would mean to break the case when admin group is not actually used, but that's probably a small enough corner case 11:21 ogra together with the checks etc 11:21 mdz pitti: I'm satisfied with that 11:21 pitti it's certainly fine for me 11:21 mdz ok 11:22 mdz DONE 11:22 pitti but I think it was important enough to talk about it 11:22 mdz DOIT 11:22 ogra phew 11:22 pitti 'k :) 11:22 mdz any other business? 11:22 pitti sleeeep === ogra finally opens a merlot 11:22 mdz I would like to talk about scheduling meeting times 11:22 mdz but we should do that when we have everyone here 11:22 mdz I'll just send email to TB about it 11:22 pitti at the beginning of next TB? 11:22 mjg59 Cool 11:22 \sh ogra: grmpf... 11:23 mdz workrave HATES ME 11:23 ogra hit it 11:23 \sh mdz: kill -9 ? 11:23 mdz meeting adjourned }}}