Technical_2005-11-29
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 <user> 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
MeetingLogs/Technical_2005-11-29 (last edited 2008-08-06 16:28:37 by localhost)