[15:02] <Keybuk> afternoon all
[15:03] <cjwatson> afternoon
[15:03]  * cjwatson wonders if mdz and sabdfl will emerge from the managers' sprint
[15:04] <mdz> I don't know where sabdfl is
[15:04] <Keybuk> Texas?
[15:04] <mdz> he's in London today but he's not with me
[15:05] <mdz> cjwatson: would you mind chairing?
[15:05] <cjwatson> initiation, huh? :-)
[15:06] <cjwatson> sure
[15:06] <cjwatson> https://wiki.ubuntu.com/TechnicalBoardAgenda:
[15:06] <cjwatson> * Patent policy (mdz)
[15:07] <mdz> heh
[15:07] <mdz> so, we need a patent policy
[15:07] <Keybuk> you were talking to Amanda about that?
[15:07] <mdz> I've asked jono to start working on it
[15:07] <mdz> but it's a relatively low priority
[15:08] <mdz> I continue to keep it on the radar because it's blocking us responding to a request for a TB ruling (ffmpeg)
[15:09] <mdz> I don't think there's anything to discuss or report in the meeting at present
[15:09] <mdz> cjwatson: mootbot?
[15:09] <cjwatson> whoops
[15:09] <cjwatson> #startmeeting
[15:09] <MootBot> Meeting started at 09:09. The chair is cjwatson.
[15:09] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:09] <cjwatson> [TOPIC] Patent policy (mdz)
[15:09] <MootBot> New Topic:  Patent policy (mdz)
[15:09] <cjwatson> Nothing to report
[15:10] <cjwatson> [TOPIC] Per-package uploader policy (persia)
[15:10] <MootBot> New Topic:  Per-package uploader policy (persia)
[15:10] <cjwatson> for the audience, there was a short thread on the TB list today
[15:10] <cjwatson> Mark proposed that the language oriented towards small sets of packages and small developers be removed, on the grounds that the same requirements should apply to larger sets too
[15:11] <cjwatson> he also recommended that the "for which there is no existing maintenance team" text be removed
[15:11] <Keybuk> ah, the chicken entrails worked ... ;)
[15:11] <sabdfl> hello all, voodoo voodo
[15:11] <cjwatson> after a bit of back-and-forth, it seems that all posters are agreed on all counts
[15:12] <persia> So this document should be generalised to cover packaging groups and package sets of arbitrary size, from 1 (member|package) to largest feasible sets?
[15:12] <cjwatson> where no other document governs
[15:12] <Keybuk> persia: to be honest, just deleting a couple of words seems to generalise it adequately
[15:12] <Keybuk> the Requirements *almost* document the requirements for any developer at this point
[15:12] <persia> Keybuk, I'd probably change the title, but yes.
[15:12] <Keybuk> and I like that
[15:12] <cjwatson> (e.g. the desktop team might want to impose slightly different requirements, although I'd expect them to be generally starting from this baseline)
[15:12] <sabdfl> +1 from me
[15:13] <sabdfl> this document doesn't address the idea of delegation, which will become relevant when we really do have packagesets
[15:13] <persia> cjwatson, So a given maintenance team may have additional requirements, but this would be the baseline set for all Ubuntu Developers?
[15:13] <mdz> I'm afraid I haven't had the chance to read the proposal yet
[15:14] <persia> sabdfl, Shall I add a section in "Commentary" to specifically address delegation?
[15:14] <sabdfl> in the xubuntu case, we would end up with a xubuntu team who could add people to themselves independently of the TB
[15:14] <mdz> and so I can't give an opinion yet
[15:14] <persia> mdz, https://wiki.ubuntu.com/UbuntuDevelopers/PerPackageUploaders
[15:14] <sabdfl> persia: i would say we defer that till later
[15:14] <cjwatson> sabdfl: but in general I would expect them to be playing by roughly the same rules
[15:14] <persia> sabdfl, OK.
[15:14] <sabdfl> cjwatson: very much so, yes, and we'd undelegate if we thought they weren't
[15:14] <mdz> persia: thanks, though I had that already.  what I'm missing is a quiet 20 minutes when I'm not doing anything else to think it over ;-)
[15:14] <cjwatson> shall we ratify this by mail, then, to give mdz a chance to absorb it?
[15:14] <Keybuk> mdz: when was the last time you honestly had a quiet 20 minutes? :p
[15:15] <Keybuk> cjwatson: +1
[15:15] <cjwatson> there do not seem to be any major issues at present
[15:15] <Keybuk> it seems we're generally in alignment, and simply need a final text to debate
[15:15] <mdz> if the rest of the board is all +1, that's sufficient to move forward and i can review/comment/propose changes later on
[15:15] <persia> If it is to be ratified by mail, I'd like to request someone else make the necessary changes to the page, to accurately represent the consensus of the TB.
[15:16] <sabdfl> i can do that in 30 secs if you'd like, why don't we move on in the agenda, and i'll whip up a diff in the background?
[15:16] <cjwatson> works for me
[15:16] <Keybuk> sure
[15:16] <cjwatson> I've been trying to absorb a list mdz sent me out of band with some pending business from a while back not on the agenda
[15:16] <cjwatson> the one I didn't recognise was:
[15:16] <cjwatson> * Blockage/issues in getting new developers into the project via MOTU
[15:17] <cjwatson> has this been resolved, or does it need further discussion? if the latter, can somebody give a quick precis?
[15:17] <mdz> this has largely merged into #4 on the same list
[15:17] <mdz> which is ArchiveReorganisation governance
[15:18] <mdz> the consensus seemed to be that the issues mainly have to do with the disconnect between the scope of MOTU and the range of contributions that developers want to make
[15:18] <cjwatson> [TOPIC] Other business
[15:18] <MootBot> New Topic:  Other business
[15:18] <mdz> sabdfl: you have an update on cdrtools
[15:18] <cjwatson> whoops
[15:18] <cjwatson> [TOPIC] cdrtools
[15:18] <MootBot> New Topic:  cdrtools
[15:18] <sabdfl> eben moglen says that we cannot ship cdrtools
[15:19] <Keybuk> rationale?
[15:19] <sabdfl> so for the moment, that is off the table
[15:19] <sabdfl> Keybuk: cddl and gpl incompatibility
[15:19] <sabdfl> there are two things that could change that
[15:19] <sabdfl> joerg could grant a specific permission on his cddl code, which he has declined to do
[15:20] <sabdfl> or the incompatibility could be resolved through discussions between cddl and gpl stakeholders
[15:20] <sabdfl> we can't influence either of those
[15:20] <sabdfl> so for us, the matter is now closed
[15:20] <Keybuk> *nods*
[15:20] <sabdfl> mdz, you planned to minute that and get it onto the ubuntu-devel-news?
[15:20] <cjwatson> in the event that the latter avenue resulted in a change to the CDDL, it would also require Joerg to release cdrtools under the new version of the licence, since the CDDL doesn't auto-upgrade (I'm told)
[15:21] <mdz> sabdfl: it will be included in the minutes from this meeting
[15:21] <cjwatson> although that would presumably be an easier sell
[15:21] <sabdfl> cjwatson: it sounded like this was more a matter of "public commitment to interpret subtleties this way rather than that way"
[15:21] <cjwatson> indeed
[15:22] <sabdfl> eben was appropriately vague about who he may or may not be talking to in that regard
[15:22] <cjwatson> as so often the case with licence interactions :-/
[15:22] <sabdfl> ultimately, it boils down to the SFLC / FSF and the people who wrote / endorse / heavily used CDDL agreeing that they agree
[15:22] <sabdfl> and of course, a judge could ruin everying afterwards
[15:22] <sabdfl> but so far, there's no movement on that front
[15:22] <sabdfl> that's all from me, mdz
[15:23] <cjwatson> all right
[15:23] <cjwatson> [TOPIC] Other business
[15:23] <MootBot> New Topic:  Other business
[15:23] <mdz> cjwatson: I sent you two other topics via PM
[15:23] <cjwatson> that other business is going to keep on losing
[15:23] <cjwatson> [TOPIC] Kernel firmware licensing
[15:23] <MootBot> New Topic:  Kernel firmware licensing
[15:24] <mdz> so, the TB was approached with concerns about unclear licensing for some of the firmware we ship
[15:24] <mdz> the kernel team has investigated this, and as of the next upload, they have cleared everything except the DVB firmware
[15:24] <mdz> which is still a work in progress
[15:24] <mdz> the work is on track to be resolved for 9.04 as planned
[15:25] <mdz> that is all, unless there are questions
[15:25] <cjwatson> are there any process changes we need to ensure that this doesn't happen in future, or is that already handled within the kernel team?
[15:26] <mdz> pgraner can answer that
[15:26] <sabdfl> pgraner: is there a list of firmware removed in that upload?
[15:26] <pgraner> cjwatson, I am reviewing all new firmware for licenses going forward and we added a milestone to the kernel schedule to review prior to relesase
[15:27] <sabdfl> are we now stricter than debian, aka whiter than white?
[15:27] <pgraner> sabdfl, I will publish to ubuntu-devel once we finish
[15:27] <mdz> sabdfl: not in the least
[15:27] <sabdfl> will this result in a significant regression of "just works" to the long tail of users?
[15:27] <mdz> sabdfl: our policy remains unchanged: we will ship it if we have the legal right to redistribute
[15:28] <mdz> the cases in question here were where the license was unknown or undocumented
[15:28] <mdz> as with every other package, we need to include the license terms for all of the contents, and in some cases that may have been missing
[15:29] <mdz> sabdfl: does that, plus the detail that pgraner will send to ubuntu-devel, address your questions?
[15:29] <sabdfl> yes thanks
[15:30] <cjwatson> [TOPIC] Kernel team upload privileges
[15:30] <MootBot> New Topic:  Kernel team upload privileges
[15:30] <sabdfl> but i had another question :-)
[15:30] <cjwatson> whoops, go for it
[15:30] <cjwatson> I'll just fix up the report afterwards
[15:30] <sabdfl> is anybody tasked with trying to obtain redistribution privileges for the pieces we didn't have them for?
[15:30] <mdz> sabdfl: not at present
[15:31] <sabdfl> mdz: i think we should, in cases where we don't know definitively that the permission would be denied
[15:31] <mdz> sabdfl: who do you think would be the appropriate person or people to chase that?
[15:32] <mdz> it will be a long and twisty process of researching and possibly negotiation
[15:32] <sabdfl> krafty, but let's discuss between you and i
[15:32] <mdz> no bandwidth
[15:32] <mdz> ok
[15:32] <Keybuk> if the firmware is already in the kernel source, isn't it more likely that the licence is simply an omission of permission?
[15:32] <Keybuk> or are you referring to only the firmware in the linux-firmware package?
[15:32] <cjwatson> we pulled in a lot of things independently
[15:33] <mdz> sabdfl: are you saying that I need to make it a priority to track down the copyright holders and contact them about this?
[15:33] <mdz> Keybuk: as cjwatson says, it's not from the kernel source
[15:33] <sabdfl> it's much lower priority than making ubuntu rock on ec2 ;-)
[15:34] <sabdfl> but it's very much in line with wanting to make ubuntu rock on the long tail
[15:34] <sabdfl> which is itself a priority
[15:34] <mdz> sabdfl: I'm sure Pete can take someone off of OEM enablement to do that then
[15:35] <mdz> to maintain the balance
[15:35] <sabdfl> ok
[15:35] <sabdfl> that's all from me, thanks
[15:35] <cjwatson> can we move on to the upload privileges, then?
[15:36] <sabdfl> https://wiki.ubuntu.com/UbuntuDevelopers/PerPackageUploaders
[15:36] <sabdfl> that has two edits from me
[15:36] <cjwatson> I'm familiar with the general topic but do not know if particular people are being proposed here
[15:36] <mdz> so I'm lacking a bit of background here, but I'm raising this on behalf of the kernel team because it is an urgent issue
[15:36] <Keybuk> sabdfl: you've reintroduced a paragraph that suggestions that per-package-uploaders are not full ubuntu developers?
[15:36] <mdz> they are short on team members who can upload the kernel, and are seeking better coverage there
[15:37] <sabdfl> Keybuk: i thought i added one which specifically said they were!
[15:37] <Keybuk> Per-package uploaders are Ubuntu developers for the purposes of polling Ubuntu developers, and are members of Ubuntu
[15:37] <sabdfl> where did i miscue?
[15:37] <Keybuk> "for the purposes of"
[15:37] <mdz> Pete sent a request to the TB on 21 January
[15:37] <Keybuk> I'd just say
[15:37] <cjwatson> can we take the perpackageuploaders bit to mail
[15:37] <cjwatson> ?
[15:37] <sabdfl> Keybuk: i thought those were all the purposes that mattered :-)
[15:37] <cjwatson> rather than interleaving it here
[15:38] <sabdfl> oh, sorry cjwatson
[15:38] <sabdfl> you mean't the kernel team's request
[15:38] <cjwatson> oh, right, sorry
[15:38] <sabdfl> i thought you meant acking the changes
[15:38] <cjwatson> the "Kernel team upload privileges" topic we're on
[15:38] <mdz> yes, see my messages above
[15:38] <cjwatson> my bad
[15:39] <cjwatson> the specific request to technical-board@ was for Stefan Bader
[15:39] <mdz> Pete sent a request to the TB on 21 January, which was +1-ed by sabdfl
[15:39] <mdz> regarding Stefan Bader
[15:39] <mdz> but I'm not aware of a decision having been taken by the board yet
[15:40] <Keybuk> We didn't actually consider it at the previous meeting, since the content of the policy was still in debate
[15:40] <mdz> they are in a bind, and so I would like to expedite this
[15:40] <Keybuk> given we've reached near-consensus on that, it may be appropriate to consider the applications now
[15:40] <Keybuk> even though we don't have a final copy?
[15:40] <cjwatson> +1
[15:40] <mdz> I don't think it's necessary to block on final text
[15:40] <mdz> and clearly sabdfl doesn't think so as he voted for it
[15:41] <cjwatson> smb_tp is not here, although we could grab him
[15:41] <sabdfl> yes, i think we can ack their request, as we're agreed on the principles and only lacking final words
[15:41] <sabdfl> at least, their request is fine given my understanding of what we're agreed on :-)
[15:42] <cjwatson> hi Stefan, thanks for joining
[15:42] <smb_tp> cjwatson, np
[15:42] <cjwatson> having reached broad consensus on what we need to grant per-package upload rights, we are considering Pete's request on your behalf for kernel upload privileges
[15:43] <smb_tp> ah ok
[15:43] <smb_tp> so what would you need from my side for that?
[15:43] <cjwatson> I understand that this is generally for stable uploads, although the privileges would be granted for the packages in general (i.e. including jaunty)
[15:44] <smb_tp> correct, I will be mainly focusing on the stable kernels and related packages (lrm, lum, linux-meta)
[15:44] <smb_tp> and lbm
[15:44] <cjwatson> I think we can waive the matter of ensuring that you understand that this isn't sole maintainership, given how the kernel team works
[15:45] <cjwatson> I'm interested in how you've found the matter of working with userspace developers (beyond things like metapackages) - have you needed to do much of that?
[15:46] <smb_tp> up to now, not yet. except for one or two cases of packages which are somewhat done by the kernel team (like module-init-tools)
[15:47] <cjwatson> Keybuk probably has more direct knowledge there than I :)
[15:48] <Keybuk> I've found that Stefan has integrated well with the kernel team, and works well with the parts that touch userspace
[15:49] <sabdfl> any other questions or concerns?
[15:49] <cjwatson> smb_tp: can you explain the current version of the kernel team's policy for which changes to take in stable releases?
[15:49] <cjwatson> [sorry, will get a move on in a moment :-)]
[15:50] <smb_tp> Currently it is to take all patches from the approriate stable kernel tree and apply them after reveiw. However there have been concerns about regression. Which was discussed on the sprint in Berlin
[15:51] <smb_tp> So we agreed to keep on doing dso for LTS releases but limit that process for other releases to 4 months after release
[15:51] <cjwatson> does that mean that for issues that we determine independently to be a problem (that nobody else has noticed yet), we're generally now pushing them round through upstream so that they can go into the upstream -stable tree?
[15:52] <smb_tp> yes. those two regressions have been pushed and are now included int the 2.6.27.14 update from upstream
[15:52] <cjwatson> that's great
[15:53] <cjwatson> ok, I've reviewed a few of Stefan's uploads before and generally had no problems
[15:53] <cjwatson> so I'm happy to go to a vote
[15:53] <cjwatson> I prepared a list of affected source packages, which I believe to be:
[15:53] <cjwatson> linux linux-backports-modules-2.6.28 linux-firmware linux-lpia linux-lpia-meta linux-meta linux-meta-rt linux-ports linux-ports-meta linux-restricted-modules linux-restricted-modules-rt linux-rt
[15:53] <cjwatson> [VOTE] Stefan Bader for upload privileges to kernel source packages
[15:53] <MootBot> Please vote on:  Stefan Bader for upload privileges to kernel source packages.
[15:53] <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:53] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:53] <cjwatson> +1
[15:53] <MootBot> +1 received from cjwatson. 1 for, 0 against. 0 have abstained. Count is now 1
[15:54] <sabdfl> +1
[15:54] <MootBot> +1 received from sabdfl. 2 for, 0 against. 0 have abstained. Count is now 2
[15:54] <sabdfl> mdz, Keybuk?
[15:54] <Keybuk> +1
[15:54] <MootBot> +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3
[15:55] <smb_tp> cjwatson, Just to be complete. Do we have to sort out the list of modules now or can we do later. There might be some gaps.
[15:56] <cjwatson> smb_tp: having established the general principle, I think we can add other source packages that match the same criteria later
[15:56] <cjwatson> with minimal discussion
[15:56] <smb_tp> ok, great. thanks
[15:56] <cjwatson> (this is implementing package sets on the cheap)
[15:56] <cjwatson> I'm going to assume that mdz has timed out, but we have 3/4 now
[15:57] <cjwatson> [ENDVOTE]
[15:57] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[15:57] <cjwatson> smb_tp: congratulations; I will implement this after the meeting
[15:57] <cjwatson> thanks for stopping in at short notice
[15:57] <cjwatson> [TOPIC] AOB
[15:57] <MootBot> New Topic:  AOB
[15:57] <smb_tp> Thanks to all. NP
[15:57] <cjwatson> in the three minutes we have remaining ...
[15:59] <sabdfl> nothing from me
[16:00] <cjwatson> ok, that's a wrap then
[16:00] <cjwatson> #endmeeting
[16:00] <MootBot> Meeting finished at 10:00.
[16:00] <sabdfl> thanks all! berlin was great, looking forward to the release sprint :-)
[16:00] <cjwatson> (I realised out of band that the list above is incomplete because I was only looking at jaunty; I will complete it using the same criteria)
[16:00] <nijaba> o/
[16:00] <ivoks> o/
[16:01] <sabdfl> roll it
[16:01]  * mathiaz waves
[16:01] <kirkland> o/
[16:01] <nxvl> \o/
[16:01] <sommer> hey all
[16:01] <Koon> o/
[16:01] <mathiaz> let's get the ubuntu server team started
[16:02] <mathiaz> #startmeeting
[16:02] <MootBot> Meeting started at 10:02. The chair is mathiaz.
[16:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <mathiaz> today's meeting agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:02] <zul> hello
[16:02] <mathiaz> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090203
[16:02] <mathiaz> [TOPIC] SRU for ebox
[16:02] <MootBot> New Topic:  SRU for ebox
[16:03] <mathiaz> sommer: I've uploaded all the packages to intrepid-proposed
[16:03] <mathiaz> sommer: ebox, libebox and ebox-usersandgroups
[16:03] <sommer> mathiaz: great thanks
[16:03] <mathiaz> nxvl: what's the next step now?
[16:03] <mathiaz> nxvl: IIRC you are/were part of the motu-sru team?
[16:04] <nxvl> i still am
[16:04] <nxvl> well, after the ACK from the motu-sru it goes to SRU-verification team
[16:04] <nxvl> they need to ack it again
[16:04] <nxvl> and then the archive admins will push that into -updates
[16:05] <mathiaz> ok - so we're at step 5 from the SRU procedure  - https://wiki.ubuntu.com/StableReleaseUpdates
[16:05] <mathiaz> kirkland: do you know how to accept SRU ?
[16:06] <kirkland> mathiaz: not yet, but i know where to find the procedure
[16:06] <mathiaz> kirkland: https://wiki.ubuntu.com/ArchiveAdministration#Stable%20release%20updates
[16:07] <mathiaz> so it seems that the ebox sru is in the hand of the archive admins
[16:07] <kirkland> mathiaz: Riddell and I didn't go over that one yet, but I'll take care of it
[16:07] <mathiaz> kirkland: great - thanks.
[16:07] <mathiaz> [ACTION] kirkland to look into accepting the intrepid SRU for ebox packages
[16:08] <MootBot> ACTION received:  kirkland to look into accepting the intrepid SRU for ebox packages
[16:08] <mathiaz> [TOPIC] Screen profiles
[16:08] <MootBot> New Topic:  Screen profiles
[16:08] <mathiaz> kirkland: ^^?
[16:08] <kirkland> mathiaz: uploaded 1.20 yesterday
[16:08] <kirkland> mathiaz: clears the bug queue
[16:08] <kirkland> mathiaz: and takes into account some advice I got from the Ubuntu UI team
[16:08]  * nxvl loves screen profiles
[16:08] <kirkland> aka Desktop Experience
[16:08] <mathiaz> kirkland: no new features? just bug fixes?
[16:08] <kirkland> aka The Bling Team
[16:09] <kirkland> mathiaz: there are new features too
[16:09] <kirkland> mathiaz: including an ec2-cost estimator for the status bar
[16:09] <mathiaz> nealmcb: have you updated the screen factoids?
[16:09] <kirkland> changelog at https://edge.launchpad.net/ubuntu/+source/screen-profiles
[16:10] <nxvl> kirkland: you haven't upload it to the ppa for testing, right?
[16:10] <nxvl> kirkland: i still have 1.15
[16:10] <kirkland> nxvl: oh, thanks for the reminded!
[16:10] <nxvl> \o/
[16:10] <kirkland> there's a screen-profiles ppa now
[16:10] <kirkland> so that you don't have to take all of the rest of my ppa-cruft :-)
[16:10] <mathiaz> kirkland: link?
[16:11] <kirkland> https://edge.launchpad.net/~screen-profiles/+archive/ppa
[16:11] <kirkland> includes packages for Intrepid and Hardy
[16:11] <kirkland> as well as Hardy/Intrepid packages for screen too, which fixes a couple of very minor (annoying) bugs there
[16:11] <kirkland> i'd like to push those through backports, i think, after Jaunty development slows down
[16:11] <mathiaz> kirkland: great - anything else to report on this front?
[16:11] <kirkland> i'm slammed until FF at least, right now
[16:12] <mathiaz> kirkland: screen in -backports?
[16:12] <kirkland> mathiaz: screen-profiles in backports
[16:12] <mathiaz> kirkland: I don't think you can push *new* packages in -backports
[16:12] <kirkland> mathiaz: oh?
[16:12] <kirkland> mathiaz: hmm, okay, sorry, then
[16:12] <mathiaz> kirkland: I'm not 100% sure though
[16:12] <kirkland> mathiaz: okay, well, now that we have a screen-profiles ppa, i'm not that worried about it
[16:13] <kirkland> mathiaz: i would like to see if zul could/would include it in the ec2 images?  (that's a separate discussion)
[16:13] <kirkland> should be easy for the Jaunty ec2 instance
[16:13] <kirkland> maybe more difficult for Hardy/Intrepid images, if it doesn't exist in the archive
[16:13] <zul> kirkland: probably for the release after this one
[16:14] <kirkland> zul: cool
[16:14] <zul> kirkland: ill talk to you after
[16:14] <sommer> kirkland: I wrote up some info for the serverguide on screen-profiles, not sure how complete it is though
[16:14] <kirkland> mathiaz: so i'd just ask for more testing
[16:14] <kirkland> mathiaz: file bugs, if things aren't working like they should
[16:14] <kirkland> mathiaz: i'd call it feature complete now
[16:14] <kirkland> mathiaz: there's nothing else i really plan before FF
[16:15] <kirkland> mathiaz: but i have some longer term ideas/plans for future versions after Jaunty
[16:15] <mathiaz> kirkland: right - keep them somewhere in a wiki page
[16:15] <kirkland> mathiaz: more flexible applet configuration of the status items
[16:15] <kirkland> mathiaz: that's *really* hard to do though
[16:15] <kirkland> mathiaz: cool, will do
[16:15] <kirkland> mathiaz: i'll probably track them as wishlist bugs in Launchpad
[16:16] <kirkland> mathiaz: i'm done
[16:16] <mathiaz> sommer: is http://doc.ubuntu.com/ubuntu/serverguide/C/index.html up-to-date?
[16:16] <mathiaz> sommer: ie is it the dev version?
[16:17] <sommer> mathiaz: nope, I'll ping mdke about it
[16:17] <mathiaz> sommer: ok
[16:17] <mathiaz> [ACTION] sommer to ping mdke about keeping doc.ubuntu.com up-to-date
[16:17] <MootBot> ACTION received:  sommer to ping mdke about keeping doc.ubuntu.com up-to-date
[16:17] <mathiaz> sommer: that way it would be easier to perform reviews
[16:18] <mathiaz> [TOPIC] Encrypted private/home with filename encryption available
[16:18] <MootBot> New Topic:  Encrypted private/home with filename encryption available
[16:18] <mathiaz> kirkland: did you make a call for testing?
[16:18] <kirkland> mathiaz: hmm, well, no...
[16:19] <kirkland> mathiaz: so Alpha4 has an encrypt-home option *working* in the installer
[16:19] <kirkland> mathiaz: in fact, i've reinstalled several of my machines with it now
[16:19] <kirkland> mathiaz: seems to be working well so far
[16:19] <mathiaz> kirkland: -server and -alternate?
[16:19] <kirkland> mathiaz: there's some kernel noise in dmesg that i'm trying to track down
[16:19] <mathiaz> kirkland: what about -desktop?
[16:19] <kirkland> mathiaz: the -server and -alternate Alpha4 are slightly broken
[16:19] <kirkland> mathiaz: encrypt-home works, but encrypted-filenames do not work
[16:20] <kirkland> mathiaz: but the daily ISO's have this fixed
[16:20] <kirkland> mathiaz: i've tested the -server and -alternate daily's
[16:20] <mathiaz> kirkland: ah ok.
[16:20] <kirkland> mathiaz: the -desktop live CD works well in Alpha4, with encrypted home and encrypted filenames
[16:20] <kirkland> mathiaz: however ....................................
[16:20] <kirkland> mathiaz: kees has brought up concerns
[16:21] <kirkland> mathiaz: and he's recommending that we might pull encrypted-home from the desktop installer
[16:21] <kirkland> mathiaz: we don't have encrypted swap support yet
[16:21] <mathiaz> kirkland: but not from -server and -alternate?
[16:21] <kirkland> mathiaz: right
[16:22] <mathiaz> kirkland: is encrypted swap still on track for inclusion in jaunty?
[16:22] <nijaba> kirkland: is the encrypted home working with shares now?
[16:23] <kirkland> mathiaz: i don't think encrypted swap will be in the installer for Jaunty, shy of a miracle
[16:23] <kirkland> nijaba: shares = nfs/cifs?
[16:23] <kirkland> nijaba: if so, no.
[16:23] <nijaba> kirkland: yep
[16:23] <nijaba> ok, too bad
[16:23] <kirkland> mathiaz: basically, there will be a manual step, to convert your swap to encrypted swap
[16:23] <kirkland> post installation
[16:23] <mathiaz> kirkland: anything else on this matter?
[16:24] <kirkland> mathiaz: i don't think we can expect desktop users to take this extra step
[16:24] <kirkland> mathiaz: and thus, we'll run the risk of leaking their encrypted data in an unencrypted form to swap space
[16:24] <kirkland> mathiaz: should the user do something like hibernate their system
[16:24] <kirkland> mathiaz: no more on this matter
[16:24] <mathiaz> great - let's move on then
[16:25] <mathiaz> kirkland: thanks for the update
[16:25] <mathiaz> [TOPIC] Update ServerGuide for Jaunty
[16:25] <MootBot> New Topic:  Update ServerGuide for Jaunty
[16:25] <mathiaz> sommer: how is it going?
[16:25] <sommer> mathiaz: getting there
[16:25] <sommer> https://wiki.ubuntu.com/JauntyServerGuide
[16:26] <mathiaz> sommer: as mentionned above if doc.ubuntu.com could be up-to-date it would help in reviewing the new sections
[16:26] <sommer> I was wondering if we need information on the new cloud virtualization stuff?
[16:26] <mathiaz> zul: soren: ^^ ?
[16:27] <mathiaz> sommer: in the wiki page, what's the difference between Done and Needs Review?
[16:27] <zul> mathiaz: i think it would be a good idea to put in the ec2 stuff in it
[16:27] <mathiaz> sommer: Done section don't need to be reviewed?
[16:28] <sommer> mathiaz: no I need to change that, really it'd be great for everything to be reviewed
[16:28] <sommer> or as much as possible anyway
[16:28] <mathiaz> sommer: ok - we have some more time after FF to do documentation review
[16:28] <sommer> zul: I think there's a wiki page on the ec2?
[16:28] <zul> sommer: there is
[16:29] <sommer> mathiaz: yeppers
[16:29] <mathiaz> [ACTION] sommer to mark all relevant section as Needs review rather then Done
[16:29] <MootBot> ACTION received:  sommer to mark all relevant section as Needs review rather then Done
[16:29] <mathiaz> zul: link?
[16:31] <mathiaz> sommer: hm - well I'm not sure if there should be a section on EC2 in the server guide
[16:31] <sommer> https://help.ubuntu.com/community/EC2StartersGuide ?
[16:31] <sommer> mathiaz: because it's proprietary?
[16:31] <mathiaz> sommer: on the eucalyptus and all the cloud stuff soren is working on make sense
[16:32] <zul> mathiaz: they use the same tools
[16:32] <sommer> mathiaz: ya I'll concentrate on that aspect
[16:33] <mathiaz> sommer: great - thnaks.
[16:33] <mathiaz> sommer: anything else on the documentation front?
[16:33] <sommer> mathiaz: don't think so
[16:33] <mathiaz> great - let's move on
[16:33] <mathiaz> that's all from last week meeting
[16:33] <mathiaz> [TOPIC] Status of the mail-stack
[16:33] <MootBot> New Topic:  Status of the mail-stack
[16:34] <mathiaz> ivoks: ^^
[16:34] <ivoks> so, i have a solution for almost everything
[16:34] <ivoks> i've created a patch:
[16:34] <ivoks> http://www.init.hr/dev/jaunty/ubuntu-mail-server.debdiff
[16:34] <MootBot> LINK received:  http://www.init.hr/dev/jaunty/ubuntu-mail-server.debdiff
[16:34] <ivoks> it introduces a new binary package in dovecot - ubuntu-mail-server
[16:34] <cjwatson> why isn't this a seed-generated thing and done in ubuntu-meta?
[16:34] <ivoks> since dovecot uses ucf, i can 'steal' /etc/dovecot/dovecot.conf from dovecot-common
[16:35] <ivoks> cjwatson: mail server?
[16:35] <cjwatson> yes
[16:35] <cjwatson> seems pretty bizarre to me to have dovecot.conf not in dovecot-common, and to have ubuntu-mail-server not be a pure metapackage
[16:35] <cjwatson> violates several expectations
[16:36] <ivoks> cause i can't overwrite config file with package that's not owner of a config file
[16:36] <cjwatson> why not just change it in dovecot itself?
[16:36] <ivoks> cause not everybody uses postfix
[16:36] <mathiaz> cjwatson: the issue here is that we'd like to change the configuration of dovecot when postfix is installed
[16:36] <ivoks> and this configuration is tied up with postfix
[16:36] <cjwatson> I think you should create a separate configuration file rather than eating dovecot.conf, then
[16:37] <ivoks> if there's no postfix, dovecot won't start
[16:37] <cjwatson> add a dovecot-postfix.conf and have ubuntu-mail-server start dovecot with that
[16:37] <cjwatson> you may have managed to get away with it technically, but I think this approach is still a policy violation
[16:37] <nxvl> there isn't a devecot.d/*.conf stuff?
[16:38] <ivoks> cjwatson: i was looking how to avoid any policy violation
[16:38] <ivoks> but maybe i missed something :)
[16:38] <mathiaz> nxvl: it wouldn't work. the configuration file has to be modified
[16:38] <cjwatson> .d should, normally, be for when a set of files in a directory are concatenated to form a single configuration file
[16:38] <ivoks> nxvl: no, not possible
[16:38] <cjwatson> ivoks: the best way to do so is to use a separate configuration file
[16:38] <nxvl> mathiaz: oh, so it's not adding directives, but to modify the existent ones, ok make sense
[16:38] <mathiaz> nxvl: yes
[16:39] <ivoks> cjwatson: outside dovecot source?
[16:39] <ivoks> as a meta package
[16:39] <ivoks> ?
[16:39] <cjwatson> ivoks: not necessary if you give it a more descriptive name, like "dovecot-postfix"
[16:39] <cjwatson> then that could sensibly be in the dovecot source itself
[16:40] <ivoks> hm, but it's more than that...
[16:40] <ivoks> it's a product, isn't not just dovecot-postfix relation
[16:40] <nxvl> then dovecot-$product
[16:40] <mathiaz> ivoks: I think that for now, we're just looking at integrating dovecot and postfix
[16:40] <cjwatson> I honestly think ubuntu-* should be reserved for pure metapackages (dependencies only), particularly when the * coincides with an existing seed name
[16:40] <ivoks> still, i'd have to change init script
[16:41] <mathiaz> ivoks: once that's working we can look into the ubuntu-mail-server task
[16:41] <ivoks> cjwatson: ok, name is irrelevant
[16:41] <cjwatson> or a separate init script
[16:41] <cjwatson> when you find yourself trying to change configuration files of another package, it's an excellent sign that the design is wrong
[16:41] <ivoks> :)
[16:42] <ivoks> ok, i'll take another approach then
[16:42] <mathiaz> ivoks: ok - it seems that sasl integration of postfix and dovecot needs more discussion
[16:42] <ivoks> i just look at ucf as a perfect tool for this, but ok... :)
[16:42] <mathiaz> ivoks: what about using dovecot LDA as a default?
[16:43] <ivoks> mathiaz: everything is included in this diff
[16:43] <mathiaz> ivoks: right.
[16:43] <ivoks> maildir, sasl, lda...
[16:43] <mathiaz> ivoks: what's the default LDA for postfix now? procmail?
[16:43] <ivoks> default is postfix
[16:43] <ivoks> postfix delivers mail
[16:44] <mathiaz> ivoks: ok
[16:44] <ivoks> ok, back to start...
[16:44] <lamont> mathiaz: if procmail is unpacked when postfix is configured, then it defaults to using procmail
[16:44] <lamont> otherwise it just delivers mail
[16:45] <mathiaz> ivoks: how about dropping a dovecot-postfix.conf file and modify the dovecot init script to use that if it's there and use dovecot.conf if not?
[16:45] <mathiaz> lamont: could a similar hook be implemented if dovecot lda is there?
[16:45] <ivoks> mathiaz: well, that's what i do, since this is wrong
[16:46] <lamont> mathiaz: not that modifies dovecot, no.  unless dovecot provided an api
[16:46] <ivoks> well, dovecot can provide lda by default
[16:46] <mathiaz> lamont: in the postinst the following command is called: postconf -e "mailbox_command = /usr/lib/dovecot/deliver"
[16:46] <ivoks> that doesn't depend on postfix
[16:47] <ivoks> i'll do what cjwatson suggested
[16:48] <ivoks> another config, another init script
[16:49] <mathiaz> ivoks: why another init script?
[16:49] <ivoks> maybe creating dovecot-common-ums?
[16:49] <mathiaz> ivoks: I'd just modify the existing dovecot init script to look for /etc/dovecot/dovecot-postfix.conf
[16:50] <ivoks> mathiaz: right, but then i have to provide new init script in binary package
[16:50] <ivoks> mathiaz: i can't change dovcot-common's init script
[16:50] <mathiaz> ivoks: that's ok. we can modify dovecot-common init script
[16:50] <ivoks> so, why now create additional -common-xyz which would conflict with plain -common
[16:50] <ivoks> :)
[16:50] <mathiaz> ivoks: anyway - let's move on
[16:51] <mathiaz> ivoks: we can discuss that later.
[16:51] <mathiaz> [TOPIC] Power management
[16:51] <MootBot> New Topic:  Power management
[16:51] <mathiaz> kirkland: ^^
[16:51] <kirkland> mathiaz: yessir
[16:51] <kirkland> mathiaz: okay, 2 things ....
[16:52] <kirkland> mathiaz: first thing i noticed, installing Jaunty yesterday, cpu frequency scaling was not immediately enabled
[16:52] <kirkland> mathiaz: i had to install powernowd
[16:52] <kirkland> mathiaz: i'm curious if we've considered adding this to the server seed before?
[16:52] <soren> kirkland: We have.
[16:52] <kirkland> mathiaz: ubuntu desktops install powernowd, and are configured to run with the "ondemand" governor by default
[16:52] <kirkland> soren: and?
[16:52] <soren> kirkland: Let me find the link...
[16:52] <soren> kirkland: I don't think it caused any objections, it just never happened.
[16:52] <kirkland> soren: ah
[16:53] <soren> I'll bet if I looked far enough down my todo list it'd be there somewhere.
[16:53] <kirkland> mathiaz: so i propose adding powernowd to the server seed
[16:53] <soren> Let me find the link, though.
[16:53] <kirkland> mathiaz: so i thought i'd bring it up here and see if there are any objections
[16:53] <kirkland> mathiaz: let me know if there's a better forum for posing that question, though
[16:54] <mathiaz> kirkland: how big is it?
[16:54] <soren> https://lists.ubuntu.com/archives/ubuntu-server/2008-September/002184.html
[16:55] <mathiaz> kirkland: would that be considered as bloating the default install?
[16:55] <kirkland> Size: 27414
[16:55] <kirkland> mathiaz: i'd think not
[16:55] <kirkland> mathiaz: on the contrary, i'd argue that not having this makes Ubuntu servers rather wasteful on the power consumption front
[16:55] <kirkland> mathiaz: always running at full blast
[16:56] <kirkland> mathiaz: http://us.archive.ubuntu.com/ubuntu/pool/main/p/powernowd/
[16:56] <kirkland> mathiaz: <30KB
[16:56] <kirkland> mathiaz: i'll chase the dependencies too
[16:57] <kirkland> mathiaz: there's a dep on "laptop-detect" that may not be necessary
[16:57] <mathiaz> kirkland: ok - I think it makes sense
[16:57] <kirkland> mathiaz: cool
[16:57] <kirkland> mathiaz: second thing here ....
[16:58] <kirkland> mathiaz: on that fresh jaunty server install, i also tested suspend and hibernate
[16:58] <kirkland> mathiaz: as well as resume
[16:58] <kirkland> mathiaz: all of them worked beautifully
[16:58] <kirkland> mathiaz: i installed pm-utils
[16:58] <mathiaz> kirkland: great
[16:58] <kirkland> mathiaz: and used pm-suspend and pm-hibernate
[16:58] <kirkland> mathiaz: and i was able to wake it up using wakeonlan
[16:59] <kirkland> mathiaz: i have filed an MIR for wakeonlan package
[16:59] <kirkland> mathiaz: i couldn't find a WoL package in main
[16:59] <mathiaz> kirkland: ok.
[16:59] <mathiaz> kirkland: anything else (we're running out time)
[16:59] <kirkland> mathiaz: there's one thing you have to do on the server to enable it to be awoken
[16:59] <mathiaz> kirkland: ?
[16:59] <kirkland> mathiaz: you have to run this ethtool command
[16:59] <kirkland> mathiaz: i'm going to try and figure out what that's actually doing
[16:59] <kirkland> mathiaz: and if that's something we could configure in /etc
[17:00] <mathiaz> kirkland: ok.
[17:00] <mathiaz> kirkland: anything else on this subject?
[17:00] <kirkland> mathiaz: so i'd like anyone to test suspend/hibernate
[17:00] <kirkland> if possible on their servers
[17:00] <mathiaz> kirkland: seems like a good candidate for a call for testing blog post
[17:00] <mathiaz> [TOPIC] Agree on next meeting date and time
[17:00] <MootBot> New Topic:  Agree on next meeting date and time
[17:01] <mathiaz> next week , same place, same time?
[17:01] <sommer> +1
[17:01] <Adri2000> no open discussion? wanted to bring up another topic
[17:01] <Adri2000> (sorry for not putting it on the agenda)
[17:01] <mathiaz> Adri2000: we're running out of time
[17:01] <mathiaz> Adri2000: add it to the agenda and we'll talk about it next week
[17:01] <mathiaz> see you all next week, same place, same time
[17:02] <Adri2000> hmm, it's about including a new upstream version, so FF is approaching...
[17:02] <Adri2000> s/so/and/
[17:02] <mathiaz> Adri2000: let's talk about that in #ubuntu-server
[17:02] <Adri2000> ok
[17:02] <mathiaz> thanks all all
[17:02] <mathiaz> #endmeeting
[17:02] <MootBot> Meeting finished at 11:02.
[17:02] <rtg> #startmeeting
[17:02] <MootBot> Meeting started at 11:02. The chair is rtg.
[17:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:03]  * apw is here
[17:03]  * cking too
[17:03]  * manjo here
[17:03]  * amitk here
[17:03] <rtg> kernel team meeting time. Pete is out this week, so I'm gonna lead.
[17:03]  * smb_tp too
[17:03] <apw> got an adjenda link?
[17:03] <rtg> agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:03] <smb_tp> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:03] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:04] <rtg> [TOPIC] Security & bugfix kernels
[17:04] <MootBot> New Topic:  Security & bugfix kernels
[17:04] <rtg> smb_tp: you're on
[17:04] <smb_tp> Yeah. Not much new
[17:04] <rtg> no promotions last week?
[17:04] <smb_tp> The Intrepid -proposed got up and also a respin of the last -proposed for Hardy wth the security updates
[17:05] <rtg> any brewing issues?
[17:05] <sconklin> sry I'm late
[17:05] <smb_tp> Hardy: a somewhat regression for Acer Aspire One
[17:05] <apw> do we have any other atom hardware to confirm if its atom or system specific?
[17:05] <smb_tp> Intrepid: just usual catchup with stable and I think a few bugfixes
[17:06] <smb_tp> Oh yes, for Hardy the intention is to add the vmware patches to fix the tsc in the next upload
[17:06] <rtg> cool, I know Alok has been waiting patiently
[17:06] <smb_tp> apw, Good point. I got an CMPC2 hee
[17:07] <rtg> anything else worth mentioning?
[17:07] <smb_tp> Beside of me being able to do my own uploads?
[17:07] <rtg> smb_tp: good point. congrats!
[17:07] <amitk> \o/
[17:08] <apw> yay!
[17:08] <cking> horrah
[17:08] <lieb> likewise
[17:08] <smb_tp> yeah. rtg rejoice. less hassle
[17:08]  * rtg gets some upload relief
[17:08] <rtg> ok, next topic
[17:08] <rtg> [TOPIC] Stable update policy change
[17:08] <MootBot> New Topic:  Stable update policy change
[17:08] <rtg> any comments about the compromise?
[17:09] <apw> wanna state the compromise in one line?
[17:09] <amitk> was it 4 months post-release?
[17:09] <rtg> correct
[17:09] <rtg> end of Feb is the deadline
[17:09] <smb_tp> I would hope to have less stable updatesby that time, so lets see how this turns out
[17:09] <amitk> we slurp in everything for 4 months and then cherry pick
[17:09] <rtg> .27 has been real active
[17:09] <apw> i think thats pretty good idea, mostly the stable churn is worse during the next lreeases -rc1->rc4
[17:09] <sconklin> seems reasonable to me
[17:10] <apw> so early adopters get more pain (potential) but those who are more circumspect with upgrades will come in later, when its lower risk
[17:10] <amitk> apw: good observation!
[17:10] <cking> potentially lower risk
[17:10] <smb_tp> agreed. just anote that the regressions we got have been somewhat cornercases and were a good option to join upstream work
[17:10] <apw> we should likely have it well stated, so that people know when the change occurs in the life of the product so they can can move later
[17:11] <smb_tp> both of tem are in 2.6.27.14
[17:11] <smb_tp> err. 15
[17:11] <rtg> we can announce the end of stable update uploads on various lists
[17:11] <rtg> ok, if everyone is in agreement, then lets move on.
[17:11] <rtg> [TOPIC] Archiving the Hardy/Intrepid OEM LPIA trees
[17:11] <MootBot> New Topic:  Archiving the Hardy/Intrepid OEM LPIA trees
[17:12] <apw> rtg there probabally should be a wiki of the policy
[17:12] <rtg> apw: are you volunteering?
[17:12] <apw> can do, i would just take your email and tart it up
[17:12] <rtg> ooh, I love the tart part :)
[17:12] <cking> steady on
[17:13] <rtg> [ACTION] Andy tarts of the stable update policy change.
[17:13] <MootBot> ACTION received:  Andy tarts of the stable update policy change.
[17:13] <rtg> ok, back to LPIA. Any objections?
[17:13] <apw> which trees are those, the ones which are ubuntu-*-lpia in our git?
[17:14] <sconklin> no, aside from some ABI cleanup, we have everything we need in the tree I think
[17:14] <rtg> sconklin: ?
[17:14] <cking> ..and where will they be archived too
[17:14] <sconklin> I meant everything in our repos
[17:14] <rtg> cking: there is an archive directory under /src/kern...
[17:14] <rtg> apw pointed out that some of the trees may have references
[17:14] <rtg> object references, that is
[17:15] <sconklin> If we can take the old -mobile-lpia repos and make them read only that would be adequate, move them to the archive directory
[17:15]  * apw will find out how to get rid of alternates if they exist where we do not want them
[17:15] <rtg> sconklin: ok, I'll work with IS to get ownership and write rights changed
[17:15] <cking> sconklin: we need iron out the minor issues with the hardy lpia lrm when tony is back tomorrow
[17:16] <rtg> cking: BCM update?
[17:16] <sconklin> cking: ok, but do it early, I'm going to be out tomorrow afternoon traveling.
[17:16] <rtg> is that what the minor issue is?
[17:16] <cking> rtg: and possibly one or two other niggles
[17:17] <rtg> sconklin: its not a big yank. we can archive LPIA anytime
[17:17] <sconklin> it doesn't matter much since future development will be on Jaunty
[17:17] <rtg> on a related topic
[17:17] <rtg> [TOPIC] Moving Jaunty LPIA into distro kernel
[17:17] <MootBot> New Topic:  Moving Jaunty LPIA into distro kernel
[17:17] <rtg> I'm starting that effort today.
[17:18] <cjwatson> yay
[17:18] <rtg> mucho packaging changes.
[17:18] <apw> we will be popular if we can get it to be the same tree, with the same abi etc
[17:18] <rtg> yeah, hopefully the ABI stuff won't come back to haunt us :)
[17:18] <amitk> apw: same abi shouldn't be a problem per se, lpia is laggin
[17:19] <rtg> I'll need to get some testing done on it, but its mostly just grunt work
[17:19] <rtg> anything else?
[17:19] <amitk> rtg: but didn't we say that we merge back _until_ OEM schedules require it to be forked again?
[17:19] <apw> rtg while you are there rip out the retag-* scripts and bin them
[17:20] <rtg> amitk: correct. I think its highly likely to happen.
[17:20] <rtg> apw: done
[17:20] <rtg> or rather, will do
[17:20] <rtg> I think we'll fork for ARM at some point as well
[17:21] <apw> just make sure we have a copy of the rebase malarky in case we need it for the forks
[17:21] <rtg> yep.
[17:21] <amitk> email to the list
[17:21] <amitk> email it
[17:21] <cking> fork == branch?
[17:21] <rtg> amitk: re: ?
[17:21] <rtg> cking: topic branch
[17:22] <apw> i'd say just leave it in the tree, ie add it to the main tree
[17:22] <apw> as an example of how, ports is now using it
[17:22] <rtg> ok, next topic
[17:23] <rtg> [TOPIC] Jaunty Status
[17:23] <MootBot> New Topic:  Jaunty Status
[17:23] <rtg> apw: how are you feeling about the bug load for Jaunty?
[17:23] <apw> most of our bug load has been intrepid still, though i am hearing about panics and problems in the halls
[17:24] <apw> it feels like people are starting to switch those with good hearts
[17:24] <rtg> with the cessation of stable updates in Intrepid, its time we turn our attention to Jaunty
[17:24] <apw> sound is still a mess, but thats mostly userspace not us
[17:24] <ogasawara> I'm seeing a few regressions come in for Intrepid - bug 326891, bug 322886, bug 323256
[17:25] <rtg> ogregressions from the prior ABI?
[17:25] <rtg> ogasawara: ^^
[17:25] <ogasawara> rtg: yes
[17:26] <rtg> at any rate, I'll make sure smb_tp focuses on those.
[17:26] <apw> ogasawara, do we mark those differently? and should we mark those specially in your stuff
[17:26] <rtg> if he hasn't already
[17:26] <smb_tp> noted I will do
[17:26] <ogasawara> apw: I tag them regression-update and I'm going to start highlighting them in my buglist
[17:26] <apw> cool
[17:26] <rtg> ogasawara: do you think they were the result of a stable update patch?
[17:27] <ogasawara> rtg: my hunch is yes, but have not dug into which specific patch
[17:27] <rtg> ok, lets make sure this doesn't escape into the wild (or -updates as it were)
[17:27] <amitk> will kerneloops make it in before feature freeze?
[17:28] <rtg> yep.
[17:28] <rtg> lieb is working to get that in place.
[17:28] <lieb> paperwork etc. today
[17:28] <rtg> Is everyone aware what feature freeze means?
[17:28] <manjo> no
[17:29] <rtg> We'll start implementing an SRU style patch process in advance of that being enforced by the SREU team.
[17:29] <rtg> SRU team, even
[17:29] <apw> so an increase in acks needed to apply etc
[17:29] <rtg> I want to approach release with a stable kernel.
[17:30] <rtg> apw: correct. we start to look real hard at what we're doing
[17:30] <rtg> I'd like to have very few substantive changes for a month before release
[17:30] <rtg> ok, lets move on.
[17:31] <rtg> [TOPIC] Suspend/Resume
[17:31] <MootBot> New Topic:  Suspend/Resume
[17:31] <rtg> do we have results posted from the sprint testing?
[17:31] <apw> suspend resume testing has been good, as per the sprint
[17:31] <ogasawara> rtg: we do, but it's on the internal wiki
[17:31] <rtg> are there plans to open up the call for testing to a wider audience?
[17:32] <ogasawara> rtg: I believe the plan is to do so around Beta
[17:32] <apw> that should occur for beta1
[17:32] <rtg> couple of weeks from now, right?
[17:32] <ogasawara> rtg: correct, I believe March 26 is Beta
[17:32] <apw> very little feedback from the internal call, but i suspect that that is more about the fact people had done testing at the sprint
[17:33] <apw> the test script itself got a real boost in the process, and should be a better test vehicle for the beta test
[17:33] <rtg> other then proprietary driver problems, were there any surprises?
[17:33] <amitk> nv
[17:33] <rtg> the 2D driver ?
[17:33] <apw> that there was only one machien which exhibited actual kernel resume failures was staggeringly good
[17:34] <apw> nv going into a flat spin on vt switch was unepected
[17:34] <sconklin> That was a good catch
[17:34] <rtg> likely the infamous lieb race condition.
[17:34]  * cking notes that one single suspend resume tests is fairly lightweight testing
[17:34] <lieb> ;)
[17:35] <rtg> cking: no body has time for 300 s/r cycles :)
[17:35] <apw> cking, agreed, i had hoped to get more testing from people from leanns call
[17:35] <apw> that test takes of the order of 30 mins total
[17:35] <pgraner> rtg: cjwatson found a keyboard hang that happens randomly, davidm has the same hang as well
[17:35] <pgraner> rtg: on suspend/resume
[17:35] <amitk> apw: 10 cycles in your script?
[17:35] <apw> pgraner, yes i had forgotten that one
[17:36] <apw> amitk, the full run is about 35 overall
[17:36] <ogasawara> amitk: I think the new script has 60 cycles
[17:36] <sconklin> I thought it was 30 - 60 seconds down to 2 in 2 second steps
[17:36] <cjwatson> pgraner: it's an X bug, though
[17:36] <apw> so all but one has been x or graphics
[17:36] <pgraner> cjwatson: cool... nice to know
[17:36] <rtg> cjwatson: punted to Bryce ?
[17:37] <apw> lieb, yours is the one we don't know about
[17:37] <apw> and we could do with getting more information on
[17:37] <lieb> yea. poor me.  there is a debubgging op ther
[17:38] <rtg> ok, done with s/r ?
[17:38] <apw> yep
[17:38] <rtg> [TOPIC] Vanilla Kernel Builds
[17:38] <MootBot> New Topic:  Vanilla Kernel Builds
[17:38] <rtg> apw has done a  great job of getting these in order.
[17:38] <apw> ok those should be ready for mainstreaming ... ie ready to be
[17:38] <apw> placed under the kernel-team user on kernel.u.c
[17:39] <amitk> cheers apw!
[17:39] <apw> rtg has volunteered to test as the first victim, to catch non-apw breaks it
[17:39] <rtg> I'll have time to play with it while I'm waiting on LPIA builds
[17:39] <apw> if it all works well then we should be able to get those who upload a stable update
[17:39] <rtg> we'll have a suite of kernels from Dapper through tip-of-Linus tree
[17:39] <apw> to also hit the script to get a mainline equivalent.  its a single mainline-build v2.6.27.16 job
[17:39] <cjwatson> the evdev driver decides that the keyboard device has subtly changed and so discards it
[17:40] <amitk> what will be the publishing mechanism (website?) for the .debs
[17:40] <amitk> ?
[17:40] <apw> for the first cut yes, on the kernel.u.c kernel user page
[17:40] <rtg> kernel.ubuntu.com/~kernel-team/...
[17:40] <apw> we have been asked to work out how to get them into a PPA and i have that on my todo
[17:41] <apw> we may be able to offer at least the lastest of each that way, .27, .28 etc
[17:41] <rtg> apw: I thought we decided 'no' on that?
[17:41] <apw> its not possible to have them all in there, we have high level pressure to try at least
[17:41] <apw> so we can say why its not possible.
[17:41] <apw> if we can get just the tips in there for the less able users to test with i think the requirements would be met
[17:42] <rtg> hmm, I thought if folks couldn't figure it out with some minimal directions, then they shouldn't be running these kernels.
[17:42] <apw> my plan was to report on whether its possible next week
[17:42] <rtg> ok, we can knock that topic around later in the week.
[17:43] <rtg> [TOPIC] Announce and publish the intended kernel version for Jaunty release
[17:43] <MootBot> New Topic:  Announce and publish the intended kernel version for Jaunty release
[17:43] <apw> rtg i tend to agree.  the utility is lower, but i think we need a conherient no if not we chose
[17:43] <rtg> is there any question in anyone's mind about this?
[17:43] <sconklin> no
[17:43] <rtg> its going to be 2.6.28, period.
[17:44] <rtg> [TOPIC] Open discussion
[17:44] <MootBot> New Topic:  Open discussion
[17:44] <rtg> anyone have general concerns?
[17:45] <apw> is everything we are aiming for jaunty, feature wise, been status checked
[17:45] <rtg> CRDA is still in progress
[17:45] <apw> just to be sure i am doing everything i am meant to be doing before FF
[17:45] <rtg> I should review some Blueprints and make sure we aren't missing anything
[17:46] <apw> sounds like an offline thing
[17:46] <rtg> yep
[17:46] <rtg> looks like thats it. next week, same time, same bat channel.
[17:46] <rtg> #endmeeting
[17:46] <MootBot> Meeting finished at 11:46.
[17:46] <amitk> bye all
[17:47] <sconklin> by
[17:47] <sconklin> or bye
[17:47] <cjwatson> rtg: I filed a bug, haven't particularly lit a fire under anyone yet
[17:48] <rtg> cjwatson: being an X bug, its in Bryce court, right?
[17:48] <cjwatson> rtg: bug 327175
[17:48] <cjwatson> rtg: yes
[17:48] <rtg> cjwatson: ok, thanks