Ubuntu Wiki

Agenda

Items we will be discussing:

• Review ACTION points from previous meeting.

• Review progress made on the specification listed on the Roadmap.

• Support for likewise-open krb5 patch.

• Launch screen by default in ec2? -- DustinKirkland

• Open Discussion.
• Agree on next meeting date and time.

Minutes

Agree on next meeting date and time

Next meeting will be on Tuesday, January 13th at 16:00 UTC in #ubuntu-meeting.

Log

[15:03] <mathiaz> #startmeeting
[15:03] <kirkland> mathiaz: good luck with that
[15:03] <Brazen> o/
[15:03] <mathiaz> kirkland: I know
[15:03] <kirkland> :-)
[15:03]  * ball sits down and shuts up
[15:03] <mathiaz> kirkland: but it also help for writting the minutes later :)
[15:04] <mathiaz> so today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[15:04] <ivoks> ok
[15:04] <mathiaz> Previous meeting minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090303
[15:04] <mathiaz> [TOPIC] SRU bug tracking
[15:04] <mathiaz> ivoks: ^^
[15:04] <mathiaz> ivoks: ready to discuss that?
[15:04] <ivoks> nope
[15:04] <ivoks> :)
[15:04] <mathiaz> ivoks: ok - let's move on then
[15:04] <ivoks> i'll add it to agenda when redy
[15:05] <ivoks> ready
[15:05] <mathiaz> [ACTION] ACTION: ivoks to add to the server team agenda an item about better SRU management.
[15:05] <mathiaz> [TOPIC] Postfix and Dovecot integration
[15:05] <mathiaz> ivoks: thanks for blogging about it
[15:05] <ivoks> right, we got nice feedback
[15:05] <ivoks> people like it so far...
[15:05] <mathiaz> ivoks: there was a bug related to the package
[15:05] <ivoks> was it?
[15:06] <mathiaz> ivoks: bug 339966
[15:06] <uvirtbot> Launchpad bug 339966 in dovecot "dangerous action: dovecot-postfix force-installs new conf file" [Low,Confirmed] https://launchpad.net/bugs/339966
[15:06] <mathiaz> I'm not sure how we should handle that.
[15:06] <ScottK> If it's accurate, that's not Low, IMO.
[15:06] <mathiaz> I've been discussing wit the reporter
[15:07] <ivoks> i see...
[15:07] <mathiaz> ScottK: I don't think dangerous is the correct word
[15:07] <ivoks> i'll work on a fix for this
[15:07] <mathiaz> ivoks: what would be the plan?
[15:08] <ivoks> i have to think about it
[15:08] <ivoks> check if dovecot.conf is changed
[15:08] <mathiaz> I'm not sure we should/could support upgrading an existing dovecot system to integrate it with postfix
[15:08] <ScottK> It can be known if the existing config is modified or not, so I think this is solvable.
[15:08] <mathiaz> not really - dovecot.conf is modified by -pop and -imap when they get installed
[15:09]  * nijaba realizes the meeting is here... o/
[15:09] <ScottK> Hmmm
[15:09] <ivoks> mathiaz: well, we can workaround it
[15:09] <ScottK> OK.  Then I'm glad ivoks is going to solve it.
[15:09] <ivoks> mathiaz: ignore ^protocols and then check
[15:09] <cemc> modified but not ignored completely
[15:09] <ivoks> if user changed protocols, he still has not working dovecot
[15:09] <ivoks> or... hm...
[15:09] <mathiaz> ivoks: OTOH I'm not sure if we should support this in the dovecot-postfix package
[15:10] <cemc> if used had imap support, and he decides to install pop3, will that break imap ?
[15:10] <ivoks> mathiaz: i understand your point of view and i agree
[15:10] <mathiaz> the dovecot-postfix package is a different kind of package since it encapsulate a script
[15:10] <mathiaz> It doesn't really ship new files - it just modifies existing configuration
[15:10] <ivoks> mathiaz: maybe we should warn user during preinst
[15:11] <ivoks> mathiaz: adding 'if you have already working dovecot, purge this package'
[15:11] <mathiaz> ivoks: I thought about that - but you cannot detect if you're installing a brand new system or if the system is an pseudo-upgrade of a running dovecot system
[15:11] <ivoks> mathiaz: we just let everybody know that?
[15:11] <ivoks> mathiaz: it's a good way to advertise all features that comes with it :)
[15:12] <mathiaz> ivoks: right - so I think we should update the description of the package
[15:12] <ivoks> or that...
[15:12] <mathiaz> ivoks: also - I think that the postinst modifies the dovecot.conf file
[15:12] <mathiaz> ivoks: to stick a comment in it
[15:12] <ivoks> nope
[15:12] <ivoks> that's in source
[15:12] <ivoks> dovecot.conf is modified during build
[15:13] <mathiaz> ivoks: hm - right.
[15:13] <mathiaz> ivoks: so may be doing this in the postinst will force a ucf merge of dovecot.conf
[15:13] <ivoks> urgh...
[15:13] <mathiaz> ivoks: that way the admin will have to see the new comment added in dovecot.conf during postinst which would have helped in the situation
[15:14] <mathiaz> ivoks: I don't know if that's the correct way to do it though
[15:14] <ivoks> give me couple of days to thing about this
[15:14] <ivoks> think
[15:14] <mathiaz> ivoks: right - could you post your solution to the bug?
[15:14] <ivoks> sure
[15:15] <mathiaz> I'm not sure about the right way to tackle this issue
[15:15] <mathiaz> let's move on
[15:15] <mathiaz> [TOPIC] Samba bug day
[15:15] <ivoks> me neither, so i have to think about it for a while :)
[15:16] <mathiaz> as you may have noticed if you read the planet next Thursday will be dedicated to triagging samba bugs
[15:16] <mathiaz> ttx: thanks for blogging about it
[15:16] <methods> how do i install an older version of package ?
[15:16] <mathiaz> nijaba: still on track to blog about it tomorrow?
[15:16] <nijaba> mathiaz: sure
[15:16] <nijaba> mathiaz: blog is ready
[15:17] <mathiaz> I'll prepare also a post to be published on Thursday
[15:17] <nijaba> waiting ti tomorrow 9am for launch
[15:17] <mathiaz> nijaba: awesome - thanks :)
[15:17] <ttx> mathiaz: who will be running the show from QA ?
[15:17] <genii> methods: Specify version on cli apt-get. eg:   sudo apt-get install something=specific-version              "specific-version"  is one which can be reported by apt-cache policy <packagename>
[15:18] <mathiaz> ttx: you
[15:18] <mathiaz> ttx: and me :)
[15:18] <incorrect> when logging in over ssh i have a log delay before the bash prompt appears
[15:18] <mathiaz> ttx: oh - QA - noone special
[15:18] <incorrect> I am not sure why its on some systems but not others
[15:18] <ttx> mathiaz: ok
[15:18] <mathiaz> ttx: the whole triagger community is there
[15:19] <mathiaz> ttx: we should be in #ubuntu-bugs to give a hand to the triagger though
[15:19] <ttx> I'll be there.
[15:19] <nijaba> incorrect: failure to do a reverse dns check is generally the issue
[15:19] <mathiaz> any developer is welcome in #ubuntu-bugs too
[15:20] <mathiaz> to help out with samba bugs
[15:20] <mathiaz> let's move on
[15:20] <mathiaz> [TOPIC] Exchange support for Evolution
[15:20] <incorrect> nicetry, I've set DNS to no, it look to be that some nodes can't talk to the ldap server for some weird reason
[15:20] <kinnaz> https://bugs.launchpad.net/ubuntu/+source/lustre/+bug/229821 <--- anyone has figured fix for what ?
[15:20] <uvirtbot> Launchpad bug 229821 in lustre "lustre-source build fails in hardy" [Undecided,New]
[15:20] <mathiaz> ivoks: ^^ how did this worked out?
[15:20] <ivoks> still nothing
[15:20] <mathiaz> ivoks: no time or not working?
[15:20] <ivoks> evolution crashes
[15:21] <mathiaz> ivoks: did you report a bug?
[15:21] <ivoks> i tested mapiprofile app today and it worked (i guess)
[15:21] <ivoks> mathiaz: not yet, i see there's new evolution-mapi in archive
[15:21] <ivoks> so i'll test with it and then report
[15:21] <ivoks> mathiaz: i guess it's cause of this particular exchange setup
[15:21] <mathiaz> ivoks: great. Keep seb128 in the loop if you find some bugs
[15:21] <mathiaz> ivoks: hm ok.
[15:22] <mathiaz> ivoks: what is mapiprofile?
[15:22] <ivoks> mathiaz: eovlution-mapi uses libmapi library
[15:23] <ivoks> mathiaz: there are also cli tools for that 'openchangeclient'
[15:23] <ivoks> i'm not sure evolution calls openchangeclient directly or trough library
[15:23] <mathiaz> ivoks: ok - so the openchange client tools are working correclty
[15:23] <mathiaz> ivoks: which means that the issue is in the evolution-mapi plugin
[15:23] <ivoks> ................i'm not sure.... yet
[15:23] <mathiaz> ivoks: ok
[15:23] <ivoks> mathiaz: output is strange
[15:24] <ivoks> lots of OK OK OK, and then error connecting
[15:24] <mathiaz> ivoks: seems that it needs more investigation
[15:24] <ivoks> i'll have to dig more into it
[15:24] <mathiaz> ivoks: cool. thanks
[15:24] <mathiaz> That's all I had from last week minutes
[15:24] <mathiaz> is there anything else to add wrt to last week meeting?
[15:25] <mathiaz> nope - let's move on then
[15:25] <mathiaz> [TOPIC] Support for likewise-open krb5 patch
[15:26] <mathiaz> so I've uploaded likewise-open patch to krb5 in jaunty
[15:26] <mathiaz> and I've received an email from the debian maintainer
[15:27] <mathiaz> the situation is that the next version of mit krb5 (1.7) will provide the same functionality (GSSAPI) but with a different implementation than the one done by likewise
[15:27] <mathiaz> however for jaunty we will ship krb 16 with the GSSAPI support from likewise-open
[15:28] <ttx> when is 1.7 scheduled ?
[15:28] <mathiaz> ttx: end of april
[15:28] <mathiaz> the likewise-open patch introduced symbols you've
[15:28] <mathiaz> exposed in your shared libraries and public headers that have diverged
[15:28] <mathiaz> from the krb5 upstream.
[15:29] <ttx> do we need the GSSAPI support for anything else than likewise-open 5 ?
[15:29] <mathiaz> that may mean we'd have to maintain API compatibility in coming releases
[15:29] <mathiaz> ttx: no - not in jaunty
[15:29] <ttx> hmm.
[15:30] <mathiaz> ttx: the reason I put the patch in jaunty is because of likewise-open
[15:30] <ttx> mathiaz: I'm not sure likewise-open 5 will make it to jaunty. If it doesn't, it would really make sense to back out that patch.
[15:31] <mathiaz> ttx: when would we know when it doesn't?
[15:32] <ttx> mathiaz: very soon. My packaging is almost ready, Ffe should follow
[15:32] <mathiaz> one proposal is to change the krb5 patch slightly
[15:33] <ttx> but it's a complete rearchitecture, not a small update. So we are quite late oin the cycle for it
[15:33] <mathiaz> to avoid supporting additional public functions
[15:33] <mathiaz> ttx: so my question is if we should look into changing the likewise-open krb5 patch to maintain API compatibility with upstream
[15:34] <mathiaz> ttx: which means modifying likewise-open
[15:34] <mathiaz> ttx: to support the modified krb5 patch
[15:36] <ttx> mathiaz: yes, probably.
[15:37] <mathiaz> ttx: ok
[15:37] <mathiaz> ttx: it seems we should discuss this a bit more with upstream
[15:38] <mathiaz> let's move on
[15:38] <ttx> mathiaz: definitely.
[15:39] <mathiaz> [TOPIC] Launch screen by default in ec2
[15:39] <mathiaz> kirkland: ^^
[15:39] <kirkland> mathiaz: zul has asked that i postpone this discussion until he's back from vacation
[15:39] <mathiaz> kirkland: ok.
[15:39] <kirkland> mathiaz: sorry
[15:39] <mathiaz> kirkland: np
[15:39] <mathiaz> [TOPIC] Open Discussion
[15:39] <mathiaz> anything else to add?
[15:40] <dantalizing> i've got something
[15:40] <ScottK> I discovered Debian Bug 518524 today
[15:40] <uvirtbot> Debian bug 518524 in amavisd-new "Fails to detect message with multiple virus payloads as infected" [Grave,Fixed] http://bugs.debian.org/518524
[15:40] <ivoks> oh, lol
[15:40] <ScottK> I've got a merge prepared and asked ubuntu release if I should upload it now or after Alpha 6.
[15:40]  * ScottK is waiting for an answer.
[15:40] <ScottK> It only affects Jaunty.
[15:40]  * ScottK is done.
[15:40] <ivoks> after alpha sounds ok, imho
[15:41] <ivoks> after all, it's a development release :)
[15:41] <ScottK> It's a quick build, so depending on where they are, I could see it either way.
[15:41] <mathiaz> ScottK: well - does it block the release of alpha6?
[15:42] <ScottK> mathiaz: No, so it isn't critical if it waits.
[15:42] <mathiaz> ScottK: I don't think so - so it can wait for after alpha6
[15:42] <mathiaz> dantalizing: yes
[15:43] <dantalizing> i just started aggregating rss on my own from multiple people, and it has evolved.
[15:43] <dantalizing> i picked up ubuntuserver.org and put a planet on it
[15:43] <dantalizing> http://planet.ubuntuserver.org/
[15:43] <dantalizing> i know there is an exisiting wp site
[15:43] <dantalizing> just wanted to throw it out to the server team
[15:43] <dantalizing> fyi
[15:44] <dantalizing> and if yall had some specific desire for it
[15:45] <jbernard> kirkland merged my changes to update-motd to add inotify support, fyi
[15:45] <mathiaz> dantalizing: great - thanks.
[15:45] <kirkland> jbernard: but i haven't uploaded it to jaunty yet :-)
[15:45] <jbernard> ill file an Ffe today
[15:45] <kirkland> but yes, jbernard did some great work to get update-motd to be able to run either in a cron-base, or an inotify based mode
[15:46] <kirkland> \o/
[15:46] <mathiaz> jbernard: awesome. Thanks for the good work!
[15:47] <mathiaz> anything else to add before we wrap up?
[15:47] <kirkland> mathiaz: 2 small things from me
[15:47] <kirkland> mathiaz: i've backported kvm-84 to build on hardy, it's available in the ~ubuntu-virt PPA
[15:48] <ivoks> er... including kernel part?
[15:48] <kirkland> mathiaz: anyone having long-standing issues with kvm-62 on hardy ... i suggest you try that package and let us know how it works for you in #ubuntu-virt
[15:48] <kirkland> ivoks: not yet, i'll work on that next
[15:48] <kirkland> ivoks: userspace only, thanks for the clarification
[15:48] <ivoks> ;)
[15:48] <kirkland> mathiaz: and second, qemu has finally release 0.10.0 (after nearly a year)
[15:49] <kirkland> mathiaz: i'm merging that now, would like to try to get that into universe for jaunty, will probably need an FFE
[15:49] <kirkland> mathiaz: but there are lots of bugs fixed
[15:50] <mathiaz> kirkland: you'd have to ask the motu-release team - ScottK would probably be able to help reviewing the FFe.
[15:50] <ScottK> For server issues I can decide.  File a FFe bug and I will review it.
[15:50] <kirkland> mathiaz: yep, 'tis why i'm mentioning it here, since it seemed that ScottK was around
[15:50] <kirkland> ScottK: thanks, will do
[15:51] <kirkland> mathiaz: all from me
[15:51] <mathiaz> great. Anything else to add?
[15:53] <mathiaz> [TOPIC] Agree on next meeting date and time
[15:53] <mathiaz> so as some of you have noticed we're currently clashing with the TB meeting
[15:53] <mathiaz> the kernel team meeting has also moved one hour forward
[15:54] <soren> Has Canada switched to DST as well?
[15:54] <mathiaz> soren: yes
[15:54] <soren> Or have we really moved it just for the benefit of the USAnians?
[15:54] <mathiaz> soren: canada and usa are in DST
[15:54] <genii> No, us canucks are forced to suffer also
[15:54] <mathiaz> OTOH the TB will also move back an hour in 4 weeks
[15:55] <mathiaz> and since TB meetings only happen every other week we would just conflict once more
[15:55] <mathiaz> so my proposal is to leave the server meeting at 15:00 UTC
[15:55] <soren> Tell me again why we moved the meeting?
[15:56] <ivoks> to make it more interesting :)
[15:56] <soren> ivoks: It's not working :)
[15:56] <mathiaz> soren: because it's the same time for northamerican
[15:56] <mathiaz> soren: and it was a better time for europeans
[15:56] <soren> mathiaz: Which makes it different for *everyone* else.
[15:56] <ivoks> northamericans, raise your hand; everybody else, raise both of them
[15:57] <sommer> o/
[15:57] <mathiaz> soren: yes - but everything will be back to the regular schedule in 4 weeks (for european)
[15:57] <Brazen> o/
[15:57] <jbernard> o/
[15:57] <soren> mathiaz: You're not making a very convincing argument :)
[15:58] <mathiaz> anyway - my point being that we'd have only one more conflict with the TB
[15:58] <mathiaz> and after that we'd be back to the regular schedule with TB (every other week), server, kernel teams meeting
[15:59] <ScottK> o/
[15:59] <soren> You could use the exact same arguments for keeping it at the same time relative to UTC.
[15:59] <soren> In three weeks it'd be normal for USAnians and Canadians.
[16:00] <mathiaz> soren: nope -because we'd have a weekly conflict with the kernel team meeting
[16:00] <soren> ...and all the while, it's been normal for Europeans.
[16:00] <soren> See, *that's* a (somewhat) useful argument.
[16:00] <mathiaz> 15:00 UTC -> 1 conflict with the TB meeting (in 2 weeks), 16:00 UTC -> 3 conflicts with the kernel team
[16:01] <soren> Alright.
[16:01] <mathiaz> so next week, in #ubuntu-meeting at 15:00 UTC?
[16:01] <ivoks> ok
[16:02]  * soren still grumbles that we have to bow to the kernel team's acceptance of American daylight savings time imperialism and not the other way around :)
[16:03]  * mathiaz points soren to #ubuntu-kernel
[16:03] <ivoks> let's kill DST
[16:03] <ivoks> it's usless anyway
[16:03] <ScottK> mathiaz: slanagasek told me to go ahead and upload, so it's done.
[16:03] <Brazen> I leave my lights on all day anyway
[16:03] <ball> I mostly run servers at UTC and let workstations calculate their offset based on that.
[16:04] <mathiaz> allright folks - thanks for attending.
[16:04] <mathiaz> happy alpha6 testing
[16:04] <mathiaz> and see you all next week, in #ubuntu-meeting at 15:00 UTC
[16:04] <ivoks> we need to have lights on car all the time :)
[16:04] <mathiaz> for the Ubuntu server team meeting
[16:04] <mathiaz> #endmeeting