[14:59] <mdz> #startmeeting
[14:59] <MootBot> Meeting started at 08:59. The chair is mdz.
[14:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:59] <mdz> This is a meeting of the Ubuntu Technical Board
[14:59] <persia> Oh, I thought that was at 14:00 UTC.
[15:00] <persia> The Asia/Oceania RMB meeting is now cancelled for this week.  Come back next week (9:00 UTC).
[15:00] <mdz> it's been at 1500 UTC since at least October
[15:01] <mdz> persia: the fridge calendar is hopeless; please consider the team calendar in Google authoritative
[15:02] <mdz> kirkland: ping
[15:02] <Keybuk> mdz: though that calendar is not available to the community
[15:02] <mdz> Keybuk: I realize.  do you have a solution?
[15:03] <mdz> the fridge doesn't even let me log in, I have no way to update it
[15:03] <mdz> this meeting has been stable for years, but never seems to be at the right time on the fridge calendar, and I don't understand why
[15:04] <Keybuk> I mailed fridge-devel about it
[15:04] <Keybuk> the mail bounced :-/
[15:04] <mdz> sabdfl is inbound
[15:04] <Keybuk> I actually did have an idea
[15:05] <dholbach> Wiki Calendar FTW:  https://wiki.ubuntu.com/Calendar?action=recall&rev=99 ! :-)
[15:05] <Keybuk> if we had a google calendar for the ubuntu community, people could add events to it by inviting the known e-mail address to the event
[15:05] <Keybuk> people known to schedule events could be given permission to add directly
[15:05] <mdz> [TOPIC] calendaring
[15:05] <MootBot> New Topic:  calendaring
[15:05] <persia> There is one.  The bot can't process it due to some bugs with the way that Google implements iCal vs. the python-ical modules.
[15:05] <persia> boredandblogging, Do you have the URL of the Google calendar for the fridge handy?
[15:05] <Keybuk> why do you need a bot?
[15:06] <persia> Keybuk, Just adjusts the topic of this channel, shows upcoming meetings, etc.
[15:06] <Keybuk> ah
[15:06] <persia> I suppose it's not needed, but it's how most people find out the schedule for stuff now.
[15:06] <Keybuk> on the calendar side, I'd just set it so it adds invited meetings by default
[15:06] <Keybuk> and generally trust people to behave
[15:06] <Keybuk> if people don't behave, someone can remove the meeting trivially and add the person to the "cannot see" list
[15:07] <cody-somerville> Keybuk, we already have a calendar like that
[15:07] <cody-somerville> oops, I see persia already mentioned that
[15:07] <sabdfl> ahoy all
[15:07] <Keybuk> cody-somerville: it doesn't seem to be very well advertised? :)
[15:07] <mdz> sabdfl: first topic, by virtue of there being a meeting conflict, is communicating our meeting time appropriately
[15:08] <mdz> the fridge is ostensibly authoritative, but it has proven very tricky to get it updated
[15:10] <Keybuk> we use calendars for a number of things
[15:10] <mdz> persia: is there anyone else who can tell us about it?
[15:10] <mdz> persia: (the google one)
[15:10] <Keybuk> most primarily for us, "booking" this channel
[15:10] <persia> Right, so unless anyone has a better solution, let's decide we want to use the Google calendar, update the fridge to point to Google, dispense with the bot until it can be fixed, and put the URL to the google calendar in the /topic.
[15:11] <persia> mdz, boredandblogging is the person who told me about it, but anyone on the News Team ought to have the information.
[15:11]  * cody-somerville has access.
[15:11] <persia> cody-somerville, What's the URL?
[15:11] <persia> cody-somerville, Can you implement something sane with it?
[15:12] <cody-somerville> http://www.google.com/calendar/embed?src=j5q85mmi6ujvjtii5s1n3li5io%40group.calendar.google.com&ctz=America/Halifax
[15:12] <MootBot> LINK received:  http://www.google.com/calendar/embed?src=j5q85mmi6ujvjtii5s1n3li5io%40group.calendar.google.com&ctz=America/Halifax
[15:12] <sabdfl> persia: +1
[15:12] <cody-somerville> persia, I think there is already a page on the fridge with the calendar embedded.
[15:12] <cody-somerville> I shall find it
[15:13] <Keybuk> we should ensure that the process for adding events to that calendar is well documented
[15:13] <Keybuk> what is the process now?
[15:13] <persia> Keybuk, mail the News team.
[15:13] <mdz> who owns this infrastructure?
[15:13] <mdz> the CC or one of its delegates?
[15:13] <sabdfl> eish
[15:13] <persia> newz2000 seems to do most of the infrastructure updates.
[15:14] <persia> News Team provides most of the direction.
[15:14] <persia> (fridge-devel was merged into News Team, as I understand things)
[15:14] <sabdfl> we've never taken a view on that - either Canonical provides infrastructure, or various folks / teams do what they need ad hoc
[15:14] <sabdfl> there are elements here of Canonical (newz2000) and ad hoc (the fridge->irc bot)
[15:14] <cody-somerville> http://fridge.ubuntu.com/node/1590 is the page on the fridge that embeds the google calendar
[15:15] <MootBot> LINK received:  http://fridge.ubuntu.com/node/1590 is the page on the fridge that embeds the google calendar
[15:15] <sabdfl> i've no problem saying that the TB could own ubuntu project infrastructure
[15:15] <sabdfl> if that would help
[15:15] <persia> Or perhaps that TB could direct it?  That saves direct responsibility, but also provides an avenue for resolution of confusion.
[15:15] <Keybuk> cody-somerville: ACCESS DENIED!
[15:15] <mdz> I don't think the tech board needs or wants to own this, we just want to make sure that people know  when the tech board meeting is
[15:16] <mdz> I would be happy to have responsibility for updating it as chair
[15:16] <mdz> but I need to know what to do and have the access to do it
[15:17] <cody-somerville> mdz, Isn't the meeting always at the same time?
[15:17] <mdz> cody-somerville: yes, which is why I'm so puzzled that it's often wrong on the fridge
[15:17] <Keybuk> to me, it seems appropriate that if it's a google calendar, people who chair teams have access to write to it
[15:17] <mdz> it changes twice a year for DST
[15:17] <cody-somerville> mdz, Because the fridge's calendar infrastructure is poor
[15:17] <mdz> cody-somerville: how do other teams update the calendar?
[15:17] <sabdfl> why does it change for DST?
[15:18] <cody-somerville> mdz, They send an e-mail and pray to $DIETY
[15:18] <persia> I just send email to the news team monthly, for the meetings I chair.
[15:18] <sabdfl> surely it's easier to fix it in Zulu time?
[15:18] <sabdfl> folks know their own DST changes better than we do
[15:18] <Keybuk> sabdfl: because many other meetings change with DST, and the tech-board overlaps with them
[15:18] <mdz> sabdfl: not when your calendar, my calendar and Keybuk's calendar are all in local time and change with DST
[15:18] <cody-somerville> If we move to the Google Calendar, folks can just e-mail the actual calendar
[15:18] <Keybuk> cody-somerville: what is the actual calendar's e-mail address?
[15:18] <cody-somerville> ie. they would invite the calendar to their event they created in their google calendar
[15:18] <cody-somerville> Keybuk, one sec
[15:19] <Keybuk> (this should all be in a wiki page)
[15:19] <Keybuk> a very clear and obvious wiki page
[15:19] <kirkland> mdz: pong
[15:19] <Keybuk> w.u.c/Calendar
[15:19] <sabdfl> is it a calendar for this channel, effectively?
[15:19] <sabdfl> or a tech board calendar, which happens to invite this channel to some events?
[15:19] <persia> sabdfl, Other events (e.g. bug days) also go there, but it's 90% for this channel.
[15:19] <mdz> http://fridge.ubuntu.com/about says to email ubuntu-news-team@lists.ubuntu.com to update it
[15:19] <MootBot> LINK received:  http://fridge.ubuntu.com/about says to email ubuntu-news-team@lists.ubuntu.com to update it
[15:20] <cody-somerville> mdz, Keybuk: Right. The google calendar is a plan of the news team. The bot currently needed some programming work to work correctly.
[15:20] <Keybuk> mdz: it does?
[15:20] <Keybuk> it says to e-mail the News Team to update the fridge itself
[15:20] <mdz> Keybuk: yes, at the end of the last calendar
[15:21] <Keybuk> it doesn't mention the calendar at all?
[15:21] <mdz> it seems cleary that what we need to do is reach out to the news team to understand how to solve this
[15:21] <mdz> not much more to talk about here
[15:21] <mdz> I'll take the action
[15:21] <cody-somerville> mdz, I'm a member of the news team
[15:21] <mdz> cody-somerville: oh dear
[15:21] <ogra> the news team was mailed several times about the TB schedule btw
[15:21] <mdz> cody-somerville: and you can't tell us how to update the calendar either?
[15:21] <cody-somerville> I can
[15:21] <cody-somerville> I just explained it :)
[15:21] <sabdfl> (03:10:49 PM) persia: Right, so unless anyone has a better solution, let's decide we want to use the Google calendar, update the fridge to point to Google, dispense with the bot until it can be fixed, and put the URL to the google calendar in the /topic.
[15:21] <mdz> cody-somerville: send an email and pray?
[15:22] <cody-somerville> sabdfl, persia++
[15:22] <sabdfl> i think we can ask the News team to change practice
[15:22] <Keybuk> cody-somerville: you said "one sec" and never told us ;)
[15:22] <sabdfl> make that an official "Ubuntu meetings and events" calendar
[15:22] <sabdfl> agree who gets to write to it, so it doesn't become too noisy
[15:22] <sabdfl> and encourage folks to subscribe through it (RSS feeds, IRC bot, News page etc)
[15:23] <mdz> https://lists.ubuntu.com/archives/ubuntu-news-team/2008-August/000164.html shows ogra saying it's at 1400 UTC.  that may have been correct at the time (BST)
[15:23] <ogra> back then it was
[15:23] <mdz> we've spent too long talking about this; we have a lot to cover
[15:23] <ogra> but afaik it never ended up on the calendar anyway
[15:23] <mdz> I'll take an action to sort this out
[15:23] <mdz> [ACTION] mdz to sort calendar issues with the news team
[15:23] <MootBot> ACTION received:  mdz to sort calendar issues with the news team
[15:23] <mdz> [TOPIC] Agenda
[15:23] <MootBot> New Topic:  Agenda
[15:24] <mdz> [LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:24] <MootBot> LINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:24] <mdz> that's the proper agenda for this meeting
[15:24] <mdz> [TOPIC] ubuntu-core-dev application from Dustin Kirkland (kirkland)
[15:24] <MootBot> New Topic:  ubuntu-core-dev application from Dustin Kirkland (kirkland)
[15:25] <kirkland> mdz: Hi, I'm here now
[15:25] <mdz> [LINK] https://lists.ubuntu.com/archives/motu-council/2008-November/001849.html
[15:25] <MootBot> LINK received:  https://lists.ubuntu.com/archives/motu-council/2008-November/001849.html
[15:25] <mdz> is kirkland's application
[15:26] <mdz> zul,cjwatson,jdstrand,kees,pitti and slangasek are named references
[15:26] <mdz> [LINK] https://wiki.ubuntu.com/DustinKirkland
[15:26] <MootBot> LINK received:  https://wiki.ubuntu.com/DustinKirkland
[15:26] <sabdfl> +1 from me on the basis of references, and my observation of kirkland in action at UDS
[15:27] <Keybuk> kirkland: One of your efforts over the last cycle has been to add a "status" command to init scripts
[15:27] <Keybuk> This has involved communication with a lot of different teams and people who care about particular packages
[15:27] <Keybuk> how do you think that went?
[15:27] <mdz> (sorry, I'm just reading the email trail now, I didn't have a chance to prep)
[15:28] <Keybuk> Especially, were there any problems or arguments you encountered?  And how did you resolve them?
[15:28] <amachu> hi
[15:28] <persia> amachu, We're cancelled for this week.  Read your mail.
[15:28] <kirkland> Keybuk: fair to partly cloudy, I'd say.  The best thing I did to help that effort, I think, was to add a status_of_proc() function to the lsb functions list
[15:28] <kirkland> Keybuk: I was able to work that function upstream into Debian
[15:29] <kirkland> Keybuk: it helped that we carried it in Ubuntu's lsb package for a little while
[15:29] <amachu> persia: Ok. got stuck in traffic :-) did any candidate turned out?
[15:29] <kirkland> Keybuk: and proved out a number of init/status scripts
[15:29] <Keybuk> was it a problem of getting others to adopt your changes?
[15:29] <kirkland> Keybuk: we covered the most important server package's init scripts
[15:30] <Keybuk> (people silently not sponsoring or changing)
[15:30] <Keybuk> or was it a problem of people vocally arguing to the change?
[15:30] <kirkland> Keybuk: sponsoring was a little tough at first, because I was very new to the community and it was remarkably difficult to get people to trust you when you're new around here :-)
[15:30] <kirkland> Keybuk: that got much easier
[15:31] <kirkland> Keybuk: and is not so much a problem now
[15:31] <kirkland> Keybuk: once I made MOTU, I was able to ease that burden by sponsoring other's changes to the universe package's init scripts
[15:31] <Keybuk> other than the obvious, how differently do you think the changes would have gone had you been a member of core-dev?
[15:31] <kirkland> Keybuk: there was some disagreement
[15:31] <Keybuk> what kind of disagreement was there?  How did you resolve the disagreements?
[15:32] <kirkland> Keybuk: well, some init scripts didn't need status actions, as I believe you brought up with respect to udev
[15:32] <kirkland> Keybuk: so it was hard to make a cut-and-dry rule
[15:33] <kirkland> Keybuk: also, it seems that because this involved "lsb", there was almost immediately controversy
[15:33] <kirkland> Keybuk: lsb seems to raise blood pressures around here, even though this item had nothing to do with certification of apps or the distro
[15:33] <kirkland> Keybuk: that was a simple lack of understanding
[15:33] <Keybuk> were you able to resolve those ?
[15:34] <kirkland> Keybuk: I think one of the first things I would do differently, were I to start this effort again, would be to right a lintian check
[15:34] <mdz> kirkland: Debian seems to be supporting LSB style init script ordering now.  In your opinion, what should our response be to that in Ubuntu, if any?
[15:35] <kirkland> Keybuk: the lintian check would put the issue in front of the package uploaders on each build, and getting that into Debian would enlist the help of a much larger community
[15:36] <sabdfl1> what did i miss?
[15:36] <kirkland> mdz: well, as I understand it, upstart is our future for init
[15:36] <kirkland> mdz: that might put us even more out of step with Debian, down the road
[15:36] <mdz> sabdfl: I will paste
[15:37] <sabdfl> thanks
[15:37] <sabdfl> kirkland: is there any sense of direction from debian on this?
[15:37] <Keybuk> kirkland: while true, Upstart will have to support old-style init scripts anyway
[15:37] <kirkland> sabdfl: this = upstart?
[15:37] <Keybuk> and supporting them makes migration a lot less relaxed, since we don't need a flag day
[15:38] <sabdfl> kirkland: clear direction from debian with regard to init strategy
[15:38] <sabdfl> last i saw it was a "general framework to allow any package to use any system"
[15:38] <kirkland> sabdfl: sorry, I haven't followed Debian's init strategy closely
[15:38] <sabdfl> Keybuk: less relaxed?
[15:38] <Keybuk> sabdfl: err, more relexed ;)
[15:39] <Keybuk> kirkland: it's also worth noting that LSB headers being wrong in Ubuntu breaks users systems when they use tools that (usually as a side-effect) reorder the init direcories
[15:39] <kirkland> Keybuk: ah, yes, I have been bitten by that, while working with superm on some mythtv issues
[15:40] <mdz> we have 20 minutes remaining and several more agenda items, 2 minute warning
[15:40] <mdz> (for this topic)
[15:40] <kirkland> Honestly, my interest in init scripts was simply in having a way to check the status of each service running on an ubuntu server
[15:40] <Keybuk> I'm done ;)
[15:40] <sabdfl> +1 from me, still ;-)
[15:40] <Keybuk> +1 from me on clear recommendation and strong technical skills
[15:41] <mdz> [VOTE] ubuntu-core-dev application from Dustin Kirkland
[15:41] <MootBot> Please vote on:  ubuntu-core-dev application from Dustin Kirkland.
[15:41] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[15:41] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:41] <mdz> +1
[15:41] <MootBot> +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1
[15:41] <mdz> sabdfl,Keybuk: care to vote now that one has actually been called?
[15:41] <sabdfl> +1
[15:41] <MootBot> +1 received from sabdfl. 2 for, 0 against. 0 have abstained. Count is now 2
[15:42] <Keybuk> +1
[15:42] <MootBot> +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3
[15:42] <mdz> #endvote
[15:42] <mdz> bah
[15:42] <mdz> kirkland: congratulations, thanks, and welcome
[15:42] <kirkland> thanks guys, cheers ;-)
[15:42] <sabdfl> i think the full expression is "bah, humbug"
[15:42] <Keybuk> bah? :)
[15:42] <mdz> [ENDVOTE]
[15:42] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[15:42] <mdz> [TOPIC] Limited main upload rights for Stephane Graber
[15:42] <MootBot> New Topic:  Limited main upload rights for Stephane Graber
[15:42] <sabdfl> stephane graber
[15:43] <Keybuk> The mootbot attacks.  The mootbot hits for -1 command-fu.
[15:43] <sabdfl> is there a url with background on this? the packages exactly?
[15:43] <mdz> Date: Mon, 06 Oct 2008 12:42:45 +0200
[15:43] <mdz> From: Oliver Grawert <ogra@ubuntu.com>
[15:43] <mdz> To: technical-board@lists.ubuntu.com
[15:43] <mdz> Cc: Stephane Graber <stgraber@ubuntu.com>
[15:43] <mdz> Subject: extended upload rights for stephane graber
[15:43] <sabdfl> i also saw a mail thread asking for mdke to have limited upload rights of docs packages
[15:43] <mdz> ltsp, ldm and ltspfs
[15:43]  * ogra looks up
[15:44] <mdz> stephane is a MOTU
[15:44] <ogra> there will be more packages though as we started splitting out i.e. ldm-themes
[15:44] <ogra> right on your request he gained motu status to get access to these packages in main
[15:44] <sabdfl> are these currently being produced by stephane and sponsored by ogra?
[15:44] <ogra> sadly he seems not to be around
[15:44] <mdz> (since December)
[15:44] <ogra> sabdfl, right
[15:44] <sabdfl> any problems so far?
[15:45] <ogra> or by other main uploaders who dont have concerns about his packagig either ... i.e. LaserJock
[15:45] <sabdfl> are any of these iso-production-critical for the desktop edition livecd?
[15:45] <ogra> nope
[15:45] <mdz> ogra: is someone planning to create a seed for these so that we can regulate access based on that?
[15:45] <ogra> mdz, a seed ?
[15:46] <mdz> ogra: https://wiki.ubuntu.com/ArchiveReorganisation
[15:46] <ogra> mdz, the source is maintained in a cross distro way on https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk
[15:46] <ogra> the tarballs used for the packages are tagged dumps from that tree directly
[15:46] <mdz> at this point, one-off ACLs like this should only be a temporary solution
[15:46] <cjwatson> seeds have nothing to do with upstream maintenance ...
[15:47] <ogra> oh, you mean an ACL team for the packaging :)
[15:47] <ogra> sure, thats doable
[15:47] <mdz> and there should be a plan to move to a seed
[15:47] <sabdfl> +1 from me, on the basis of lots of collaboration, limited impact of a mistake and long effective maintenance of the packages
[15:47] <mdz> (or whatever they're being called...last I checked it was seeds)
[15:47] <mdz> cjwatson: is that still accurate?  I see discussion of other names on the wiki page
[15:47] <cjwatson> mdz: I am attempting to review the UDS discussion at the moment
[15:47] <mdz> ogra: no, I don't
[15:47] <cjwatson> (slightly stymied by audio problems on my laptop)
[15:48] <mdz> ogra: I mean the list of packages which that team can upload
[15:48] <cjwatson> until I've done that I'd rather not give an inaccurate answer, but I am going to have it done by the call on Thursday
[15:48] <ogra> mdz, ah, k (i need to read up on that topic more, i'm not up to date on this yet and jum meetings atm)
[15:48] <ogra> *jump
[15:48] <mdz> I'm happy to ack this request but only if someone is on the hook to transition it to post-ArchiveReorg world order
[15:49] <mdz> ogra: is that you?
[15:49] <ogra> well, i'll do that
[15:49] <cjwatson> I will keep it on my list of things that need attention once we have a clearly defined new world order
[15:49] <mdz> ok
[15:49] <sabdfl> call for a vote?
[15:50] <mdz> [VOTE] Upload ACL for stgraber including ltsp, ldm and ltspfs
[15:50] <MootBot> Please vote on:  Upload ACL for stgraber including ltsp, ldm and ltspfs.
[15:50] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[15:50] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:50] <mdz> +1
[15:50] <MootBot> +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1
[15:50] <sabdfl> +1
[15:50] <MootBot> +1 received from sabdfl. 2 for, 0 against. 0 have abstained. Count is now 2
[15:50] <mdz> Keybuk: ?
[15:50] <Keybuk> +1
[15:50] <MootBot> +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3
[15:51] <mdz> [ENDVOTE]
[15:51] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[15:51] <sabdfl> zuupa
[15:51] <mdz> [ACTION] mdz to get ACL updated for stgraber
[15:51] <MootBot> ACTION received:  mdz to get ACL updated for stgraber
[15:51] <mdz> [TOPIC] cdrtools
[15:51] <MootBot> New Topic:  cdrtools
[15:51] <mdz> this will be quick
[15:51] <mdz> I haven't heard anything on this since early December
[15:51] <mdz> it's in Joerg's hands as I understand it
[15:52] <mdz> we've identified the legal language which needs to be added, and asked Joerg to make the change as recommended by SFLC
[15:52] <mdz> I'll send out a ping to see where it stands
[15:52] <mdz> [ACTION] mdz to ping regarding cdrtools
[15:52] <MootBot> ACTION received:  mdz to ping regarding cdrtools
[15:52] <Keybuk> without having read what you've asked to add,
[15:52] <mdz> [TOPIC] ArchiveReorganisation and governance impact thereof
[15:52] <MootBot> New Topic:  ArchiveReorganisation and governance impact thereof
[15:52] <Keybuk> I'm still concerned that any grant for cdrtools will permit any GPL application to link to any non-GPL library
[15:53] <mdz> we have a conference call at 1400 UTC on Thursday with the MOTU Council to discuss t his
[15:53] <mdz> Keybuk: I can forward you the thread offline if you like; it's not a very good read
[15:53] <mdz> given that we're constrained on time, I guess we'll defer further discussion on this to the call
[15:54] <mdz> sabdfl,Keybuk: please make sure you're adequately prepared for that discussion in advance though
[15:54] <mdz> [TOPIC] Patent policy
[15:54] <MootBot> New Topic:  Patent policy
[15:54] <mdz> We have an outstanding inquiry regarding how to respond to patent concerns in a package
[15:54] <mdz> this highlighted for me the need for a general policy on this to help developers decide what to do
[15:54] <mdz> but as far as I'm aware there is no one working on it at the moment
[15:54] <mdz> I do not have time to do it
[15:55] <sabdfl> mdz: are you reording the agenda specifically?
[15:55] <sabdfl> this could be a long conversation
[15:55] <sabdfl> i'd rather get to some of the other bits this week
[15:55] <mdz> sabdfl: no, just getting to some quick topics first
[15:56] <mdz> this is just a call for help, nothing to discuss in this meeting
[15:56] <sabdfl> this is not one of them
[15:56] <sabdfl> :-)
[15:56] <mdz> but it is blocking a request someone made of the tech board months ago
[15:56] <mdz> and the unresponsiveness/ineffectiveness of the tech board at the moment was a concern discussed at UDS
[15:56] <mdz> so I felt it only fair to highlight it
[15:56] <sabdfl> in general, i don't think we fold in the face of suggestions of patent infringement
[15:56] <sabdfl> just because there may be a patent in some jurisdiction is no reason for us not to ship code
[15:56] <sabdfl> we need to look at the details, case by case
[15:57] <sabdfl> there will be cases where we DON'T ship code, because we think that would generally put users in a bad situation
[15:57] <mdz> sabdfl: so you disagree that we should have a documented policy?
[15:57] <sabdfl> and others where we do, because there is insufficient clarity
[15:57] <sabdfl> no, but i don't think it can be simplistic
[15:57] <mdz> someone needs to own the problem of getting consensus on this and documenting it
[15:58] <mdz> or at a minimum, to respond to the inquiry that's been raised
[15:58] <mdz> neither of these can be me, I'm afraid
[15:58] <mdz> we are out of time and I know you want to get to the nominations, so let's move on
[15:59] <mdz> [TOPIC] Technical Board nominations
[15:59] <MootBot> New Topic:  Technical Board nominations
[15:59] <cjwatson> I did respond to the enquiry that reached me, but I felt unable to give an authoritative answer on the legal liability Canonical's prepared to accept as a distributor
[15:59] <mdz> sabdfl: all yours
[15:59] <cjwatson> (and instead made what helpful comments I could)
[15:59] <sabdfl> https://edge.launchpad.net/~ubuntu-dev/+polls
[15:59] <mdz> cjwatson: I appreciate that, thanks
[15:59] <sabdfl> cjwatson and keescook have agreed to stand in a run-off election for a single new place on the TB
[15:59] <mdz> wow, only 7 days to vote
[15:59] <sabdfl> voting is now open, and runs for a week
[16:00] <sabdfl> i haven't discussed any "platform position" or "meet the candidates" ideas
[16:00] <sabdfl> as we're in somewhat new territory :-)
[16:00] <sabdfl> both have said that the other guy would be brilliant too ;-)
[16:00] <sabdfl> where should we announce the ballot?
[16:00] <sabdfl> it's of course open to MOTU and core-dev
[16:00] <mdz> ubuntu-devel-announce and right quick
[16:01] <sabdfl> okdokey
[16:01] <sabdfl> should we move on?
[16:01] <mdz> this is the last topic on the agenda
[16:01] <mdz> [TOPIC] AOB
[16:01] <MootBot> New Topic:  AOB
[16:01] <cjwatson> I do have one piece of AOB if we can make it fit
[16:02] <cjwatson> https://wiki.ubuntu.com/FoundationsTeam/Specs/OemTrackingId involves namespace assignment for a file filled in by redistributors of Ubuntu
[16:02] <cjwatson> in my review of the spec, I objected to having a free-for-all namespace with no arbitration body or record
[16:02] <mdz> [LINK] https://wiki.ubuntu.com/FoundationsTeam/Specs/OemTrackingId
[16:02] <MootBot> LINK received:  https://wiki.ubuntu.com/FoundationsTeam/Specs/OemTrackingId
[16:02] <cjwatson> and suggested that there should be a fairly simple registry with the TB arbitrating disputes if necessary
[16:03] <cjwatson> feel free to tell me to defer to later if you don't think this is something that can be dealt with immediately
[16:03] <mdz> I'm happy for the TB to be the custodian of that list in the absence of an obvious fit with an existing team or a need for a new one
[16:03] <mdz> sabdfl,Keybuk: any objections?
[16:03] <Keybuk> reading the specification, it looks like most of this is already implemented anyway?
[16:03] <Keybuk> mdz: no, I agree we should own that namespaced
[16:04] <cjwatson> Keybuk: ish, some renaming needs to happen
[16:04] <sabdfl> there are some issues in that spec - the shipt / dowload delta
[16:04] <cjwatson> there is an existing implementation providing some similar things, but it doesn't meet all the requirements
[16:04] <mdz> yes, but cjwatson isn't asking about those (and from his comments I think he has the situation in hand)
[16:04] <cjwatson> yeah, we had a follow-up call after my comments; telegraphic notes at the bottom which I will fold into the spec
[16:04] <sabdfl> +1 on the registry
[16:05] <mdz> cjwatson: does that address your issue?
[16:05] <cjwatson> I do need to talk to somebody about the shipit issue but I think that somebody is probably Jane/Henrik rather than the TB
[16:05] <cjwatson> mdz: yes, that's fine, thank you; I will nominate a page and mail a note to the TB
[16:05] <mdz> ok, let's wrap then, thanks all
[16:05] <mdz> #endmeeting
[16:05] <MootBot> Meeting finished at 10:05.
[16:05] <Keybuk> thanks
[16:06] <sabdfl> thanks all
[16:07] <mathiaz> all right folks - let's get the Ubuntu Server Team meeting going.
[16:07] <mathiaz> #startmeeting
[16:07] <MootBot> Meeting started at 10:07. The chair is mathiaz.
[16:07] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:07] <nijaba> o/
[16:07] <sommer> o//
[16:07] <persia> \o
[16:07] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:07] <ScottK-desktop> o/
[16:07] <jdstrand> o/
[16:08] <MianoSM> o/
[16:08] <mathiaz> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090106
[16:08] <mathiaz> [TOPIC] Screen Profiles
[16:08] <MootBot> New Topic:  Screen Profiles
[16:08] <mathiaz> kirkland: ^^?
[16:08] <zul> hello
[16:08] <kirkland> mathiaz: yessir!
[16:08] <kirkland> mathiaz: it's totally awesome now
[16:08] <adityag> here in for member, i am sorry because i am late, i just came to know about it
[16:09] <kirkland> mathiaz: uploaded to universe for jaunty
[16:09] <kirkland> mathiaz: in my ppa for hardy/intrepid
[16:09] <kirkland> mathiaz: nijaba has done some excellent work on the configurator
[16:09]  * nijaba blushes
[16:09] <kirkland> mathiaz: it's very fast to start up now (i'm caching the updates-available information)
[16:09] <mathiaz> kirkland: so what's up with the taskbar ?
[16:09] <kirkland> mathiaz: i plan to blog about it today
[16:10] <kirkland> mathiaz: clarify the question?
[16:10] <adityag> any one there  ?? in here for the first time
[16:10] <mathiaz> kirkland: awesome.
[16:10] <mathiaz> kirkland: last time we talked about implemented a taskbar in screen
[16:11] <mathiaz> kirkland: is this something still being worked on? implemented?
[16:11] <kirkland> mathiaz: it currently looks like this: http://people.ubuntu.com/~kirkland/Screenshot.png
[16:11] <kirkland> mathiaz: the 3-color "\o/" is our approximation of the spirit of the Ubuntu logo (also, it's 1/3 of the circle of friends)
[16:12] <kirkland> mathiaz: Ubuntu 8.10 is pulled from the lsb-release information
[16:12] <kirkland> mathiaz: there are 66 updates available for my system right now
[16:12] <nijaba> mathiaz: you really should try it out, sounds like you have not yet
[16:12] <kirkland> mathiaz: my system load is 0.40
[16:12] <mathiaz> kirkland: right. There is an action about a taskbar from last week minutes.
[16:12] <kirkland> mathiaz: I have 2 CPUs, currently operating at 800MHz
[16:12] <kirkland> mathiaz: and 4G of RAM available
[16:12] <mathiaz> kirkland: having a way to load applets into the taskbar
[16:12] <ScottK-desktop> kirkland: Congratulations on core-dev BTW.
[16:12] <kirkland> mathiaz: and the time/date
[16:13] <kirkland> ScottK-desktop: thanks for your support!  \o/
[16:13] <kirkland> mathiaz: that's a very difficult item;  i don't plan on implementing that any time soon
[16:13] <kirkland> mathiaz: screen-profiles is quite usuable now, and provides a lot of good information
[16:14] <kirkland> mathiaz: i'd like to focus now on finding/fixing bugs
[16:14] <kirkland> mathiaz: and improving the usuability
[16:14] <mathiaz> kirkland: great.
[16:14] <kirkland> mathiaz: i'm going to contact the Desktop User Experience team
[16:14] <kirkland> mathiaz: and ask them if they can give this a look over
[16:14] <mathiaz> anything else to add regarding screen-profiles?
[16:14] <mathiaz> it seems that was is required now is more testing
[16:14] <kirkland> mathiaz: right
[16:14] <kirkland> mathiaz: and then ....
[16:15] <mathiaz> [ACTION] kirkland to write a blog post about screen-profile
[16:15] <MootBot> ACTION received:  kirkland to write a blog post about screen-profile
[16:15] <kirkland> mathiaz: i think we should revisit this in 2-3 weeks, and consider if the ubuntu screenrc should be the system default /etc/screenrc
[16:15] <kirkland> mathiaz: so that any user who runs screen gets this magic
[16:15] <kirkland> mathiaz: in Ubuntu
[16:16] <mathiaz> kirkland: seems like an idea to discuss.
[16:16] <mathiaz> let's move on.
[16:16] <kirkland> mathiaz: yes, and we need strong confidence of no breakage to do so, IMHO
[16:16] <jdstrand> kirkland: what about doing used/total for memory, rather than just total?
[16:16] <kirkland> jdstrand: i like that idea
[16:16] <kirkland> jdstrand: what about a percentage?
[16:17] <kirkland> jdstrand: i'd be interested in seeing how we can accomplish this in as few characters as possible
[16:17] <kirkland> jdstrand: I'm trying to stay within 80 columns
[16:17] <jdstrand> kirkland: I like that you give the total, and would be fine with a percentage as long as total was still there
[16:17] <kirkland> jdstrand: you see that we have a little more space
[16:17] <kirkland> jdstrand: k
[16:17] <jdstrand> kirkland: but, really, percentage is most important I think
[16:17] <mathiaz> kirkland: jdstrand: let's discuss the improvement somewhere else
[16:17] <jdstrand> (if you had to choose)
[16:17] <mathiaz> [TOPIC] SRU for ebox
[16:17] <MootBot> New Topic:  SRU for ebox
[16:17] <jdstrand> np
[16:17] <mathiaz> sommer: ^^?
[16:17] <mathiaz> zul: ^^?
[16:18] <zul> uploaded this morning waiting for motu-sru
[16:18] <mathiaz> all the bugs have been filed/updated?
[16:18] <sommer> bugs filed for the needed patches
[16:18] <sommer> mathiaz: yeppers :)
[16:18] <mathiaz> and the motu-sru team is subscribed to all of them?
[16:19] <sommer> mathiaz: should be
[16:19]  * ScottK-desktop is pinging them right now.
[16:19] <ScottK-desktop> What bug?
[16:19] <mathiaz> sommer: excellent work!
[16:19] <sommer> ScottK-desktop: bug #273486
[16:20] <sommer> bug #314606'
[16:20] <sommer> and bug #255368
[16:20] <mathiaz> great - thanks for the work sommer and zul
[16:21] <zul> np
[16:21] <sommer> np
[16:21] <ScottK-desktop> motu-sru is looking at them now.
[16:21] <mathiaz> That's all the ACTION left from last week meetings
[16:21] <mathiaz> anything else to add wrt to last week meeting?
[16:21] <sommer> ScottK-desktop: cool, thanks
[16:22] <mathiaz> allright. Let's move on then.
[16:22] <mathiaz> [TOPIC] libmysqlclient-dev package (MySQL 5.1) in jaunty
[16:22] <MootBot> New Topic:  libmysqlclient-dev package (MySQL 5.1) in jaunty
[16:22] <mathiaz> The current version of libmysqlclient15-dev in jaunty is provided by mysql 5.1.
[16:23] <mathiaz> Which is a transitional package.
[16:23] <mathiaz> As a result pkgs in main that build-depends on libmysqlclient15-dev don't build
[16:23] <mathiaz> ex: ooo
[16:23] <mathiaz> so the plan is
[16:24] <mathiaz> 1. upload a new version of mysql-dfsg-5.1 that doesn't build libmysqlclient15-dev transitional package
[16:24] <mathiaz> instead it would build libmysqlclient16-dev
[16:25] <mathiaz> mysql-server, mysql-client would also not be provided by mysql-5.1
[16:25] <mathiaz> and mysql-common would be renamed to mysql-common-5.1
[16:25] <zul> oh crap sorry about that
[16:25] <mathiaz> 2. upload a new version of mysql-dfsg-5.0 with a version of 5.1.30really5.0.75
[16:25] <persia> Why does it need libmysqlclient16-dev, if it's not going to have the transitional package: can't it just use libmysqlclient-dev ?
[16:26] <mathiaz> so that libmysqlclient15-dev, mysql-server, mysql-client and mysql-common are provided by mysql-5.0 again.
[16:26] <ScottK-desktop> persia: I think you want to provide a way to specifically build-dep on the 5.1 -dev
[16:26] <mathiaz> persia: the current 5.1 package from debian works like this:
[16:26] <mathiaz> persia: it provides a transitional pacakge libmysqlclient15-dev which depends on libmysqlclient-dev
[16:27] <mathiaz> persia: debian 5.1 doesn't have libmysqlclient16-dev
[16:27] <persia> ScottK-desktop, mysql-dfsg-5.0 doesn't provide "libmysqlclient-dev" as a package name, which is why I thought it might be useful to use the current Debian name.
[16:27] <mathiaz> however mysql-5.0 provides libmysqlclient15-dev (which provides a virtual package libmysqlclient-dev)
[16:27] <persia> mathiaz, Right.  I just don't understand the value of the new package, unless there's some other use to which libmysqlclient-dev is expected to be put.
[16:28] <persia> Ah, virtual packages.
[16:28] <persia> Right.  Nevermind.
[16:28] <jdstrand> mathiaz: is Debian planning to be able to have 5.1 and 5.0 in the archive at the same time?
[16:28] <mathiaz> right now in Debian there is only 1 version in mysql.
[16:28] <mathiaz> jdstrand: good question.
[16:28] <zul> i doubt it
[16:29] <ScottK-desktop> persia: Oh.  I thought it did.
[16:29] <mathiaz> jdstrand: considering that 5.1 in experimental provides a binary pkg libmysqlclient-dev, I don't think so.
[16:29] <jdstrand> if they do, this really sounds like something we'd want to collaborate on with them
[16:29] <persia> ScottK-desktop, as pointed out, it virtually does :)  We're both right.
[16:29] <ScottK-desktop> ;-)
[16:30] <jdstrand> mathiaz: if not, we'll need to make *sure* that everything upgrades ok when 5.1 in debian replaces 5.0
[16:30] <ScottK-desktop> jdstrand: Yes, but we've got two issues: Fix it now so OOo will build and Do it right/talk to Debian.
[16:30] <mathiaz> even if Debian doesn't plan to provide both packages, we - at least for jaunty - will provide both 5.1 and 5.0
[16:30] <mathiaz> one in main (currently 5.0) and one in universe (5.1)
[16:30] <mathiaz> universe (currently 5.1)
[16:30] <ScottK-desktop> Although Kubuntu has hopes of getting Amarok back in Main, so there may be bits of 5.1 that need to get promoted.
[16:31] <ScottK-desktop> They are still trying to figure out how small those bits can be.
[16:31] <mathiaz> so it seems that we'd have to provide libmysqlclient16-dev as a binary package from mysql-5.1
[16:32] <mathiaz> so my question is: what happens if both libmysqlclient15-dev and libmysqlclient16-dev provide a virtual package libmysqlclient-dev?
[16:32] <mathiaz> is this something that should be done^^?
[16:32] <ScottK-desktop> And as we've discussed before, we either need to get Akonadi moved to 5.1 or make sure all the needed bits are co-installable.
[16:32] <persia> It's acceptable, as long as they conflict.
[16:32] <mathiaz> or only one should provide libmysqlclient-dev
[16:32] <jdstrand> mathiaz: with your plan, what happens when Debian replaces 5.0 with 5.1 and we try to sync in a future version of Ubuntu? and when users go intrepid -> jaunty -> ...
[16:32] <mathiaz> persia: right. What should be the build-dep then?
[16:33] <mathiaz> should package build-dep on libmysqlclient-dev?
[16:33]  * jdstrand is worried about an even bigger delta
[16:33] <mathiaz> or on libmysqlclient{15,16}-dev?
[16:33] <persia> mathiaz, Whichever version is desired.  I'd recommend having libmysqlclient16-dev not provide libmysqlclient-dev for now.
[16:33] <persia> By not providing, packages won't get built against 5.1 by accident.
[16:34] <mathiaz> jdstrand: I don't know.
[16:34] <ScottK-desktop> Step 3 of the plan that mathiaz and I discussed last night was "Beg Debian to do an Epoch and get things back in sync versionwise."
[16:34] <mathiaz> persia: right. mysql-dfsg-5.1 should only provide packages that are new.
[16:35] <mathiaz> persia: and conflicts with necessary existing packages.
[16:35] <mathiaz> persia: but not replacing existing packages.
[16:36] <persia> mathiaz, Right.
[16:36] <mathiaz> allright - so to summarize:
[16:36] <persia> ScottK-desktop, may not need an epoch, depending on the Debian transition plan, and status at both jaunty release and jaunty+1 release.
[16:37] <mathiaz> 1. mysql-5.1: provides libmysqlclient16-dev
[16:37] <ScottK-desktop> Maybe
[16:37] <mathiaz> 2. mysql-5.0: version 5.1.30really5.0.75
[16:37] <mathiaz> I'll upload these after the meeting.
[16:38] <mathiaz> [ACTION] mathiaz to upload mysql packages to fix libmysqlclient-dev package in jaunty.
[16:38] <MootBot> ACTION received:  mathiaz to upload mysql packages to fix libmysqlclient-dev package in jaunty.
[16:38] <mathiaz> anything else to add on this specific subject?
[16:38] <zul> yep sorry about this
[16:38] <ScottK> mathiaz: Double check there aren't any other conflicting package names.
[16:39] <mathiaz> ok - let's move on.
[16:39] <mathiaz> [TOPIC] WebArchitecture
[16:39] <MootBot> New Topic:  WebArchitecture
[16:39] <mathiaz> yann hammon around?
[16:40] <nijaba> mathiaz: no yann2 around...
[16:40] <mathiaz> nijaba: ok.
[16:40] <mathiaz> let's move on.
[16:40] <mathiaz> [TOPIC] Ubuntu Server on NAS devices
[16:40] <MootBot> New Topic:  Ubuntu Server on NAS devices
[16:40] <mathiaz> persia: ^^?
[16:41] <persia> Yep.  I have some nice little ARM servers: hobbyist versions of the Buffalo consumer NAS devices.  I'd like to run Ubuntu on them.  Further, I'd like this to be reasonable for normal users.
[16:41] <persia> What level of support should I expect, and what can I do to make that be "full"?
[16:42] <zul> ergh..
[16:42] <zul> i dont think the server team is equipped to support NAS devices
[16:43] <persia> OK.  What's missing?
[16:43] <zul> manpower for one
[16:43] <persia> To do what?
[16:43] <mathiaz> persia: first step: are all the packages required for running a NAS device built on ARM?
[16:44] <mathiaz> persia: then - which services you'd provide? nfs/cifs?
[16:44] <persia> mathiaz, I think so.  I would be expecting to run a fairly standard Ubuntu Server base configuration.  FTBFS is something I'm happy to chase towards that goal.
[16:44] <mathiaz> persia: ssh/sftp/avahi?
[16:44] <mathiaz> persia: I think almost all the main component are there.
[16:45] <persia> Well, that's why I wanted to discuss it.  I'll personally mostly use ssh, but I suspect it's interesting in a wider sense for other services (for other people).
[16:45]  * ScottK could see a NAS task if we had a scalable way to list out tasks....
[16:45] <mathiaz> persia: the only touchy thing is the administrative interface
[16:45] <persia> How so?
[16:45] <mathiaz> persia: do we have a standard way to create an admin interface for non-geeky users?
[16:46] <ScottK> Sounds like a good Jaunty+1 spec topic to me.
[16:46] <persia> Wasn't there a framework involving lenses that was intended to do that?  Or does ebox do that?
[16:46] <mathiaz> ScottK: agreed.
[16:46] <nijaba> mathiaz: isn't that what ebox solves?
[16:46] <mathiaz> yes.
[16:47] <mathiaz> ebox could do the job. we'd have to test it.
[16:47] <persia> I can certainly add an agenda item to the next UDS, but I'd think that there's probably a light-weight solution that might be interesting in the meantime, without extra packages, etc.  I don't really mind a geeky interface.
[16:47] <mathiaz> it may need to be trimmed down to only provide the necessary components for a NAS device
[16:48] <persia> Are there services in a default server that shouldn't be run?
[16:48] <mathiaz> persia: the default install doesn't run any service listening on the network
[16:48] <persia> Just because they sell it as a NAS device doesn't mean it's not a general-purpose computer.
[16:48] <mathiaz> persia: not even ssh
[16:49] <persia> The default Server install doesn't?  Oh.  I thought it did.
[16:49] <nijaba> persia: no, it is proposed as a task
[16:49] <ScottK> persia: I'd say "Make it work as a command line managed NAS" is a good Jaunty goal and "Make it non-geek friendly" is a good Jaunty+1 goal
[16:50] <persia> ScottK, That seems completely reasonable to me.  What can I do to address the Jaunty goal?
[16:50] <mathiaz> persia: so IMO we should first make sure that the file services are working correctly on ARM
[16:50] <mathiaz> persia: that means making sure samba and nfs are working correclty
[16:50] <ScottK> mathiaz: I think this is a reasonable task for tasksel.
[16:50] <mathiaz> persia: as well as dhcp.
[16:50] <persia> mathiaz, Is that just a matter of pushing an ARM install through the already published testcases?
[16:50] <ScottK> That or a metapackage of some kind.
[16:51] <mathiaz> persia: right - there is a testcase for samba
[16:51] <mathiaz> tasksel already has a samba server tasks.
[16:52] <mathiaz> persia: how important is that the NAS device provides NFS?
[16:52] <persia> mathiaz, I don't care about NFS personally, although maybe someone does.
[16:52] <mathiaz> persia: IMO it's just a matter of testing.
[16:52] <persia> I've hardware, so I'll volunteer to run an ARM install of Server through the test cases: shall I just file bugs on anything that doesn't work?
[16:52] <mathiaz> persia: making sure that samba, ssh and dhcp are working with the ARM platform
[16:53] <mathiaz> persia: seems like a good plan to me.
[16:53] <ScottK> Would we want anything different in an arm-server kernel that it's worth the trouble to make/maintain it?
[16:53] <mathiaz> and as ScottK mentionned, tackling the admin interface could be done during the next cycle.
[16:53] <persia> While I'm willing to chase some of the bugs, should I expect assistance from others to get them closed?
[16:53] <mathiaz> even though ebox may fit the bill.
[16:54] <persia> ScottK, There's already about 6 flavours of ARM kernel: I think NAS-specific is probably a jaunty+1 thought.
[16:54] <ScottK> persia: As I'm pretty sure you know, NCommander has been doing a lot of portability work on armel.
[16:54] <ScottK> persia: OK.
[16:54] <ScottK> He could probably be encouraged to help.
[16:54] <persia> Yes, I've been seeing that, which is one of the reasons I brought this up.
[16:57] <mathiaz> ok - let's move on.
[16:57] <mathiaz> I won't run the Open discussion topic.
[16:57] <mathiaz> If someone wanted to add something, please edit the Meeting wiki page
[16:57] <mathiaz> so that we can discuss it next week.
[16:57] <mathiaz> https://wiki.ubuntu.com/ServerTeam/Meeting
[16:58] <mathiaz> [TOPIC] Agree on next meeting date and time
[16:58] <MootBot> New Topic:  Agree on next meeting date and time
[16:58] <mathiaz> next week, same time, same place?
[16:58] <nijaba> +1
[16:58] <sommer> +2
[16:58] <ScottK> mathiaz: One quick think libdb4.3 died this week.
[16:58]  * ScottK waves at vorian who is working on the lidbd consolidation stuff.
[16:59] <mathiaz> ScottK: great. thanks for reporting that.
[16:59] <mathiaz> so see you all next week, same time, same place
[16:59] <mathiaz> and happy iso testing for Alpha3 - due this week!
[16:59] <mathiaz> #endmeeting
[16:59] <MootBot> Meeting finished at 10:59.
[16:59] <nijaba> Thanks for running the meeting mathiaz
[17:00] <pgraner> Time for the kernel team meeting
[17:00] <pgraner> #startmeeting
[17:00] <MootBot> Meeting started at 11:00. The chair is pgraner.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:01]  * smb_tp joins
[17:01]  * cking is here
[17:01] <pgraner> [TOPIC] Security & bugfix kernels - Hardy, Intrepid
[17:01] <MootBot> New Topic:  Security & bugfix kernels - Hardy, Intrepid
[17:01] <pgraner> smb_tp: How do we sit? Any news?
[17:02] <smb_tp> Hardy: -proposed kernel went to -updates on the 8th
[17:02] <smb_tp> this will be the one getting into the .2 release
[17:03] <rtg> smb_tp: of course, there are updates immediately following because we missed some stable updates
[17:03] <smb_tp> Intrepid: there has been one regression I am currently fighting about the backlight stuff. I think the solution is near but this will move the date for the update here
[17:03] <smb_tp> Right, there were also some updates we tried to get into as well wich will be in the one -proposed that follows quite soon
[17:04] <pgraner> smb_tp: how did they get missed?
[17:04] <smb_tp> Thee were 6 patches in the pull from 2.6.24.3 to 2.6.24.4 which I missed out. All at the beginning.
[17:05] <apw> were they all sparc specific?
[17:05] <rtg> pgraner: it was about the time we changed our stable update policy.
[17:05] <pgraner> smb_tp: any procedural changes we can make to make it simpler in the future
[17:05] <smb_tp> No not all. Three were some net proto and one ip4 sand two sparc
[17:05] <rtg> missing them was a one time occurrence.
[17:06] <smb_tp> pgraner, No I think it was justbecause it was done late.
[17:06] <pgraner> rtg: what would you propose?
[17:06] <smb_tp> Some patches got in before some not
[17:06] <pgraner> smb_tp: ok
[17:06] <rtg> pgraner: what do you mean? propse what? I don't think there will be  a problem in the future.
[17:07] <smb_tp> Some went in with different names. So if we now include them all as soon as a -stable update gets out it will be simpler
[17:07] <apw> now that we are taking 'all' of them we should find it easier to valdiate it by simple counting in the future
[17:07] <pgraner> rtg: you said it was "about the time we changed our stable update policy", I was asking for elaboration
[17:07] <rtg> uh, it was about _the_ time (sorry)
[17:07] <rtg> oh, never mind.
[17:07] <pgraner> rtg: Ah, ok that makes more sense then, never mind
[17:08] <pgraner> smb_tp: cool, just don't want to make it a habit.
[17:08] <smb_tp> Ok, T61 works now with latest intrepid test kernel
[17:08] <smb_tp> Not intentionally for sure
[17:08] <apw> that t61 thing is our last (known) brightness regression yes?
[17:09] <smb_tp> Yes, AFAIK
[17:09] <rtg> no, Kano complained about Vostro regressions this AM
[17:09] <rtg> but that was Jaunty, never mind.
[17:09] <smb_tp> That thing is strange in ways that it should work with api but doesn't
[17:09] <smb_tp> with the -11 default kernel?
[17:10] <smb_tp> He surelydoes not use my ppa kernel
[17:10] <rtg> smb_tp: never mind, he was complaining about Jaunty
[17:10] <smb_tp> Oh yeah
[17:10] <smb_tp> But might be the same fix
[17:11] <apw> yeah as the original regression was stuff backported from mainline which had hit jaunty
[17:11] <rtg> smb_tp: thats likely, but we have time to work on it.
[17:11] <smb_tp> The last patch to smart identify which laptops can do acpi seems dangerous
[17:11] <smb_tp> right
[17:11] <smb_tp> So back to intrepid. Now I can get that kernel uploaded to -proposed
[17:11] <rtg> cool
[17:11] <smb_tp> But it will probably not be taken into -updates tomorrow
[17:12] <rtg> Greg has 2.6.27 stable updates on deck.
[17:12] <apw> i saw a bunch of stuff getting queued
[17:12] <rtg> looks like some amd64 iommu stuff that is important
[17:12] <smb_tp> These would follow after I get this one up
[17:13] <smb_tp> There is also the next un of CVEs going
[17:13] <pgraner> rtg: look like any ABI breakers in that set?
[17:13] <smb_tp> s/un/run/
[17:13] <rtg> hell if I jknow, I only look at titles so far
[17:13] <pgraner> rtg: ack
[17:13] <pgraner> smb_tp: anything else?
[17:14] <smb_tp> No I thin I am done
[17:14] <pgraner> [TOPIC] Jaunty Status
[17:14] <MootBot> New Topic:  Jaunty Status
[17:14] <pgraner> How does the kernel look for Alpha 3?
[17:14] <rtg> all but armel looks good.
[17:14] <rtg> armel is giving me a real PITA
[17:15] <apw> the suspend-resume bits made the kernel
[17:15] <pgraner> rtg: lets hold armel until the arm topic
[17:15] <rtg> ok
[17:15] <rtg> apw completed Jaunty lpia this AM
[17:15] <pgraner> apw: cool, I'd like to talk about the testing methodology and reporting for suspend/resume for a min
[17:16] <pgraner> ogasawara: how do you see the bug report handling happening?
[17:16] <rtg> I think the big Jaunty/kernel change is gonna be ext4 support in the installer and grub
[17:16] <cking> which is a good thing
[17:16] <pgraner> rtg: understood, lets get to that in a sec
[17:16] <ogasawara> pgraner: for suspend/resume testing I can send out automated calls for testing
[17:17] <apw> right now we are still waitiing for the apport and pm-utils changes to be accepted and uploaded
[17:17] <apw> pitti being away is making life difficult on that score
[17:17] <pgraner> apw: has anyone poked on the right folks to get them in?
[17:17] <ogasawara> apw: it'll make it in time for Alpha3?
[17:17] <BenC> apw: do you need someone else to review?
[17:18] <apw> reviewers can only help if you have the time, the changes are on the bug
[17:18] <BenC> apw: at least pm-utils, we should be able to do
[17:18] <BenC> apport I would leave for pitti
[17:18] <rtg> or kees
[17:19] <BenC> apw: point me at the bugs, and I'll check into them after lunch
[17:19] <apw> i did talk to slangasek so he was aware of our aim and our desire to hit alpha-3
[17:19] <apw> BenC, will do ...
[17:19] <ogasawara> apw:  what's the bug # that you're using for tracking?
[17:19] <apw> bug #316419
[17:20] <apw> all three changes are linked on there, the kernel stuff is already in
[17:20] <pgraner> ogasawara: once the bugs come in, are you going to do the usual triage process, do we need to help you in anyway?
[17:20] <ogasawara> pgraner: I can do the usual triage.  should be simple since I can use the tags.
[17:21] <BenC> apw: got it, thanks
[17:21] <ogasawara> pgraner: I'll yell for help if I need it
[17:21] <pgraner> ogasawara: ok, lets assign them to apw since he is running on lead, he can then work with the rest of the team and further assign as needed, work for you apw?
[17:22] <apw> we can see how that works and modify later if not
[17:22] <apw> when we have more idea of the volume.  as they have tags we don't necessarily need to assign them till we start wortk on them i guess
[17:23] <pgraner> apw: great, what I don't want to happen is they don't get looked at and fall thru the cracks. This way you can start to do a grouping of like issues etc...
[17:23] <apw> yep.  its a focus so we need to be on top of them
[17:24] <pgraner> ogasawara: when do plan on putting the CFT out? And initially it should be to the canonical engineers for the Alpha releases, then to the Community for Beta and beyond.
[17:25] <ogasawara> pgraner: ah, so if we want just canonical engineers for Alpha's I'd suggest maybe sending email to distro team mailing list for call for testing
[17:25] <apw> yeah we just need to make sure the apport side is out before we ask
[17:25] <ogasawara> pgraner: assuming Alpha3 releases on the 15th as expected, I can put the call for testing out the day after
[17:26] <apw> ogasawara, i'll let you know when i know all the bits are in place
[17:26] <ogasawara> apw:  cool thanks.  I'll wait to hear from you first.
[17:26] <pgraner> ogasawara: yep. We'd like to concentrate on a group of known hardware and work on getting that working right, then open to the community
[17:26] <pgraner> apw: did you and sconklin get all the docs and troubleshooting wikis updated?
[17:27] <apw> i need to get that done too
[17:27] <pgraner> apw: cool, make sure ogasawara has all the links for the CFT email when done :-)
[17:28] <pgraner> apw: feel free to ask for help from other folks as you see fit
[17:28] <apw> will do ...
[17:28] <pgraner> BenC: how did you make out with the ACPI suspend removal?
[17:29] <BenC> pgraner: things are completed, but I need to send out the testing request
[17:30] <pgraner> BenC: Cool, you might want to update apw's wiki's with the info so its documented there and people don't try to use it as a testing mechanism
[17:30] <BenC> It's mostly a no-op in a lot of cases, so I'm not too concerned if I do an upload later today for A3, but I want to make sure no one gets serious regressions
[17:30] <BenC> pgraner: ok
[17:31] <pgraner> BenC: cool, thanks
[17:31] <rtg> BenC: do we still use pm-suspend?
[17:31] <pgraner> [ACTION] BenC to update wiki pages on removal of ACPI suspend method
[17:31] <MootBot> ACTION received:  BenC to update wiki pages on removal of ACPI suspend method
[17:31] <pgraner> [ACTION] apw to update wiki docs on suspend/resume and send links to ogasawara
[17:31] <MootBot> ACTION received:  apw to update wiki docs on suspend/resume and send links to ogasawara
[17:32] <pgraner> [TOPIC] Vanilla Kernel Builds
[17:32] <MootBot> New Topic:  Vanilla Kernel Builds
[17:32]  * NCommander wakes up
[17:32] <BenC> rtg: I'd have to check that...I'm still not 100% on how all of this stuff interacts
[17:32] <pgraner> We did have the action from UDS to get the vanilla kernel builds working,
[17:32] <apw> i have the bones of the work for that, i put the actions in your wiki page yesterday
[17:33] <rtg> hasn't happened yet
[17:33] <pgraner> rtg: understood
[17:33] <apw> i need to investigate how that fits in with multiple PPA's
[17:33] <pgraner> when do we think we can get it wired up and running
[17:33] <cking> is this automatic building of vanilla kernels?
[17:33] <rtg> apw: oh, I didn't know you'd had time.
[17:33] <apw> yeah the idea is automatic builds of general tips matching the kernels
[17:33] <pgraner> apw: can you hand some of the research off to others?
[17:33] <BenC> cking: semi...I think it's only done for each rcX
[17:34] <apw> and ones matching the tip of linus
[17:34] <cking> aha
[17:34] <apw> pgraner, i think i need to set down my thoughts and progress somewhere and send it out, as the naming needs some thought so we don't collide with updates of our kernels etc
[17:35] <BenC> apw: the versioning mess is the reason we've been procrastinating about this till now :)
[17:35] <BenC> going to be hard to make it sensible
[17:35] <pgraner> apw: ok, you and I can take that off line and see when would be best to work on it and bring back the results to this forum
[17:35] <apw> pgraner, agreed
[17:36] <pgraner> [TOPIC] ARM tree aka.... the mess
[17:36] <MootBot> New Topic:  ARM tree aka.... the mess
[17:36] <pgraner> apw:  can you give everyone the latest...
[17:36]  * apw looks confused
[17:36] <rtg> apw has been working on lpia
[17:37] <BenC> yeah, I think rtg own's "the mess" :)
[17:37]  * pgraner is confused sorry.... too many things going on
[17:37] <rtg> mostly all I've been trying to do is get it to armel build.
[17:37] <NCommander> I can say something on the ARM trees
[17:37] <rtg> NCommander: go ahead
[17:37] <pgraner> NCommander: sure
[17:37] <NCommander> As it stands
[17:37] <NCommander> We still don't have a kernel in the archive with udebs
[17:38] <NCommander> so d-i is blocking on the kernel
[17:38] <BenC> didn't last kernel upload include armel d-i, or am I confused?
[17:38] <cjwatson> last one tried but didn't have udebs
[17:38] <rtg> my build issues are related to getting udebs done
[17:38] <cjwatson> I am happy to help with udeb build problems
[17:38] <NCommander> rtg, i can look into this, I'm currently idle waiting on something else
[17:38] <BenC> rtg: are you having trouble with the way d-i stuff in the build is handled?
[17:38] <rtg> its minor stuff, but time consuming
[17:38] <cjwatson> easiest is if you send over a .deb, then the udebs can be tested on any architecture
[17:39] <rtg> BenC: yep, empty modules when kernel-wedge runs. stuff like that.
[17:39] <cjwatson> I would like to be involved in non-trivial udeb changes in general anyway, since they often affect me further down the line
[17:39] <apw> is it kernel-wedge which makes the d-i stuff?
[17:39] <cjwatson> yes
[17:39] <apw> i have been noting errors from kernel-wedge during normal builds
[17:39] <apw> splits on null values, may be relevant
[17:39] <NCommander> Its probably something in d-i that broke, I had this issue with the ports kernel for awhile
[17:39] <cjwatson> rtg: if you send me a .deb and your current diff to debian/d-i/ if any, I can take care of it
[17:39] <cjwatson> NCommander: no
[17:40] <cjwatson> the kernel's udeb build process is a build-dependency of d-i, not the other way round
[17:40] <rtg> cjwatson: I'm having trouble getting that far. the build unit I have isn't really stable.
[17:40] <cjwatson> surprised you're getting as far as kernel-wedge then :)
[17:40] <apw> did we get a porter yet? i thought that was in progres
[17:40] <rtg> cjwatson: I haven't yet, at least on the babbage.
[17:41] <cjwatson> even a filesystem tree wouldn't hurt, though I realise you've been having fs problems
[17:41] <rtg> cjwatson: I'm not sure I follow? a file system tree/
[17:41] <rtg> ?
[17:42] <cjwatson> as in the build tree
[17:42] <rtg> its just the jaunty git repo
[17:42] <cjwatson> the tree with .o and .ko files in
[17:42] <cjwatson> not the source
[17:42] <rtg> ah
[17:42] <rtg> i have it for one flavour
[17:42] <apw> debian/build/foo
[17:42] <rtg> it take a looong time
[17:43] <rtg> about 3 hours per flavour
[17:43] <cking> eek
[17:43] <cjwatson> all I mean is, if you can send me the bits that actually require a real arm machine to build, then I can probably make use of that to fix debian/d-i/
[17:43] <rtg> I think the buildd must be quite a  bit faster
[17:45] <rtg> cjwatson: I don't suppose you could convine Adam or elmo to let you use a buildd for awhile?
[17:45] <rtg> convince, even
[17:46] <apw> pgraner, were you chasing down what  happened to the porter for arm?  i had the feeling that it existed but wasn't integrated, perhaps that is available for someone like cjwatson
[17:47] <pgraner> apw: last I heard was that the hardware was with elmo
[17:47] <pgraner> apw: and was told he was taking care of it
[17:47] <cjwatson> rtg: I doubt it
[17:47] <apw> so cjwatson might be able to 'borrow' that
[17:48] <cjwatson> I suspect it will be just as quick to get the porter box switched on for everyone as it would be to get it switched on for just me
[17:48] <cjwatson> but I will try to find out what's happening with it
[17:48] <apw> heh works for me
[17:48] <pgraner> cjwatson: I'll follow up with elmo after this
[17:48] <rtg> cjwatson: that would be good. these babbage boards are shaky at best
[17:49] <pgraner> ok, lets move on as we are running short on time....
[17:50] <pgraner> [TOPIC] Open Discussion
[17:50] <MootBot> New Topic:  Open Discussion
[17:50] <lool> rtg: I have an evm here running jaunty; I could give you ssh access if it helps; it's not very fast and has relatively low memory, but ogra built kernels on i
[17:50] <pgraner> Open floor ....
[17:50] <lool> it
[17:50] <lieb> how responsive is linux-dvb? I'm working on #181759
[17:51] <rtg> lool: you know, I could probably do the same. I have a fire breather.
[17:51]  * BenC reminds ppl of the open week...kernel session on Friday for dkms usage
[17:51] <lieb> and the h/w spt for the cx88 dev has been around for a while and was in pre-hardy.  the vendors stuff has not made it to the git
[17:51] <pgraner> BenC: thanks that a good point
[17:51]  * apw queries what an open week is
[17:52] <pgraner> dholbach: can explain the best....
[17:52] <cjwatson> rtg mentioned ext4 earlier; there's been at least one report so far of grub failing to boot an upgraded ext3->ext4 filesystem (only by mail so far, ubuntu-devel-discuss, Subject: Problem with patched grub1 & ext4)
[17:52]  * pgraner hopes dholbach is nearby and can jump in quickly
[17:52] <apw> lieb, is that stuff we are carrying and is not making its way upstream?
[17:52] <cjwatson> so that may be one cking needs to dive into ...
[17:52] <ogasawara> apw: https://wiki.ubuntu.com/UbuntuDeveloperWeek
[17:52] <cking> cjwatson: will do
[17:52] <cjwatson> https://wiki.ubuntu.com/UbuntuDeveloperWeek
[17:52] <cjwatson> oh, Leann beat me to it
[17:52] <ogasawara> :)
[17:53] <lieb> apw, not only that, no one either pulled it or pushed it.  I'm thinking to push it just to get it done
[17:53] <pgraner> would be good for the new guys to attend...
[17:53] <BenC> Yeah, you guys can help seed questions
[17:53] <apw> lieb, yeah i think it does need someone to take and push things that are lingering
[17:53] <BenC> nothing worse than dead air, and me rambling for an hour
[17:53] <pgraner> BenC: you are giving it again right?
[17:53] <BenC> pgraner: right
[17:54] <lieb> that's what I figured.  wanted to know what the pattern/history was
[17:54] <pgraner> Anyone have anything else?
[17:55] <apw> just that the lpia kernel is close to being uploadable
[17:55] <apw> (for jaunty)
[17:55] <pgraner> apw: do you know what the drop dead time is from slangasek?
[17:56] <apw> no not got that info
[17:56] <rtg> pgraner: its not an A3 deliverable
[17:56] <BenC> pgraner: since it's just linux-lpia, it should be low impact
[17:56] <apw> i thought it was the end of today
[17:56] <pgraner> rtg, BenC: davidm and crew need it for a contractual reasons I found out this AM
[17:56] <rtg> on A3?
[17:58] <pgraner> rtg: yep
[17:58] <pgraner> lool: can you confirm?
[17:58] <slangasek> what's dropping dead?
[17:58] <pgraner> rtg: we can take this offline with the mobile team...
[17:59] <pgraner> slangasek: latest time you can upload it
[17:59] <lool> pgraner: I don't think it's critical for A3 itself
[17:59] <lool> I think it's just important that we get up-to-date lpia support with patches and all in jaunty
[17:59] <pgraner> lool: davidm told me this AM that it was key for one partner
[18:00] <lool> Ok; I'm probably not aware enough to confirm then
[18:00] <pgraner> lool, apw: lets take this offline and we can sort it as we are out of time
[18:00] <pgraner> [TOPIC] Next meeting
[18:00] <MootBot> New Topic:  Next meeting
[18:00] <pgraner> Same time next week.
[18:00] <pgraner> rtg: can you run it as I'm on travel Mon & Tues of next week
[18:01] <rtg> pgraner: yeah, I think I'm still at home.
[18:01] <pgraner> ok, great
[18:01] <pgraner> thanks
[18:01] <pgraner> #endmeeting
[18:01] <MootBot> Meeting finished at 12:01.
[19:36] <dantalizing> 'sup huats
[19:40] <huats> hello dantalizing !
[21:01] <ziroday> @schedule Singapore