=== doko_ is now known as doko === dholbach__ is now known as dholbach === dholbach_ is now known as dholbach === noy_ is now known as noy === Quintasan_ is now known as Quintasan === yofel_ is now known as yofel === bigbash is now known as zz_bigbash [14:59] #startmeeting [14:59] Meeting started Thu Oct 6 14:59:20 2011 UTC. The chair is NCommander. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [14:59] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [15:00] [link] https://wiki.ubuntu.com/ARM/Meeting/2011/20111006 [15:00] hi [15:01] [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-arm.html [15:02] * davidm waves [15:02] i dont think we need to look at specs for O [15:02] * NCommander waves back [15:02] Yeah [15:02] lets use the time at the end to look at ÜP specs instead [15:02] [topic] ARM Server Status (NCommander, Daviey) === meetingology changed the topic of #ubuntu-meeting to: ARM Server Status (NCommander, Daviey) [15:03] * davidm is upset that the HTC Flyer pricing was a mistake [15:03] ogra_: I have nothing drafted for a meeting on it. We can do that next week [15:04] server side, I have nothing new to report [15:04] NCommander, we need to have the drafts registered by next week [15:04] ogra_: I'm aware. [15:04] so we need to discuss them today [15:05] at least who adds which [15:05] ogra_: then I'd appericate it if you had asked me to bring it up before the meeting or even put it on the agenda. [15:05] (and i doubt we have anything beyond banshee to discuss at all anyway) [15:05] NCommander, will do next time, but that doesnt change the deadline now :) [15:06] and you just said you are aware [15:06] ogra_: we have the P Blueprints page, and we've gone over it in this meeting before. [15:07] right [15:07] who registers and drafts which one then ? [15:07] i assume david will not do all he has assigned [15:08] I'm drafting all the ARM server ones and will assign them after UDS after discussions with the team [15:08] sigh. Can we stick to the agenda? I have added Blueprints to the meeting wiki. [15:08] NCommander: anything kernel related? [15:08] GrueMaster, thanks ! [15:08] [topic] Kernel status === meetingology changed the topic of #ubuntu-meeting to: Kernel status [15:08] ppisati: not to my knowledge, anything to report? [15:09] yes, lets stick to the agenda, i didnt mean to start a discussion (since i thought it was clear we have to do it today) [15:09] nothing new to report this week [15:09] no new ac100 either, I was kind of hoping upstream fixes speaker sound - ongoing [15:09] NCommander: nope, that's why i was asking [15:09] janimo, its fixed :) [15:09] janimo, see #ac100 [15:09] janimo, time for a zero day SRU i'd say ;) [15:10] (after some testing) [15:10] ogra_, well, marvin says one more patch is pening [15:10] pending [15:10] k [15:10] If the patchset is small, I'd accept it today. :P [15:10] But 0-day works too. [15:10] ppisati, xranby reported stability issues on omap4 [15:11] i assume GrueMaster doesnt do many heavy load tests so that went unnoticed it seems [15:11] indeed, would be nice to have it for release [15:11] janimo, ++ [15:11] ogra_: i'll ping him [15:11] great, there should also be a bug open already [15:11] ogra_: I haven't been able to get past the installer on dailys. [15:11] GrueMaster, yeah, thats what i mean :) [15:11] omap4? [15:11] yep [15:12] panda [15:12] uhm [15:12] on cdimage i don't see any daily for omap (that is not a preinstalled one) [15:13] ppisati: All our images are preinstalled. [15:13] except netboot [15:13] btw, today i reinstalled an omap4 preinstalled and it was ok [15:13] ppisati:The installer I am referring to is oem-config. It is part of Ubiquity. [15:13] great to hear ! [15:13] but yes, couldn;'t get ubiquity to start [15:13] And is part of every preinstalled image. [15:13] ppisati: Couldn't get it to start? [15:14] nope [15:14] crash [15:14] ppisati: Was there a bug filed? [15:15] infinity: didn't check, i thought there was something wrong on my side [15:15] Possibly. [15:15] https://bugs.launchpad.net/ubuntu/+source/ubiquity [15:16] but it seems there are quite a bit open [15:16] bugs [15:17] [topic] ARM Porting/FTBFS status (NCommander, janimo) === meetingology changed the topic of #ubuntu-meeting to: ARM Porting/FTBFS status (NCommander, janimo) [15:17] banshee ! :) [15:18] so lets make a decision ... since RC doesnt happen today we have a bit wiggle room [15:18] GrueMaster: and I did some work on finding the root of the crash and some workaround attempts Allailed === fader_ is now known as fader [15:18] Sadly, it builds. It even installs. [15:18] NCommander, GrueMaster do you see any chance for a fix (even an SRU) in time ? [15:18] ogra_: I say we ship withe banshee despite the breakge. Changing el seeds is el suidice IMHO at this point [15:18] if not i'll change the seeds right after meeting [15:19] NCommander, i have approval and RB was tested [15:19] ogra_: I think the odds are on par with you quitting smoking:-/ [15:19] what is the status on banshee [15:19] I don't want to ship broken as it could be months for an SRU [15:19] i only want to ship banshee if there are realistic chances that we can get a fix [15:19] RB doesn't support ubuntuone from what I could tell. [15:19] GrueMaster: it should [15:20] davidcalle, i'll happily ship it broken if i can get a word from NCommander that there is a chance for a zero day SRU or some such [15:20] RB support predated bansheesupport [15:20] The banshee issue feels like a missing package or setting issue. [15:20] It does not but I don't care working player beats broken player with unknown repair [15:20] if thats clearly impossible lets drop it [15:20] the less dependence on a framework known to be dodgy on ARM, the happiler I am [15:20] so its all based on michaels judgement [15:21] ogra_: you gotapproval to ship RB. Make it happen [15:21] NCommander, what is the likely hood of a fix by next Thursday? [15:21] and since he said that i would stop smoking before it gets fixyed ... [15:21] * ogra_ lights a cigarette and opens a terminal in the seeds dir :) [15:22] davidm: Unlikely. Its crashing in pure mono code, and I've yet to get mdb to work properly under ARM [15:22] davidm: nor has GrueMaster managed to getone going throguh MonoDevelop [15:22] yeah, lets keep banshee for P :) [15:22] how about ftbfs beyond banshee ? [15:22] davidm: The fix could happen as early as today or as late as it takes. In my opinion, it is not an easy nut to crack, even with debugging symbols. [15:23] OK then lets pursue RB for release, and fix banshee later if at all possible [15:23] yep [15:23] or concentrate on having a rock solid banshee in P [15:23] and dont waste time on O [15:23] [topic] ARM Image Status (ogra, NCommander) === meetingology changed the topic of #ubuntu-meeting to: ARM Image Status (ogra, NCommander) [15:23] they build and work [15:23] for everyone bug GrueMaster [15:24] For most people. [15:24] s/bug/but even [15:24] mx5 is very slow though [15:24] janimo, how is mx5 ? [15:24] heh, snap [15:25] I have yet to get through oem-config without it respawning several times. [15:25] everyone who tested it says the same [15:25] well, it installs and its a "tech preview" [15:25] on omap4. [15:25] GrueMaster, for me once it respanwed was the sign the system was installed [15:25] but hmm, maybe not ocnsistently [15:25] janimo, that doesnt help [15:25] I know [15:25] I believe the mx5 issues are swap related. I seemed to get a bit better performance once I had a working swapfile. [15:25] since you still have jasper and ubiquity installed then [15:26] And no user account some of the time. [15:26] GrueMaster, but it has ~800Mb of RAM no? The beagle was snappier with less RAM [15:26] GrueMaster, oh, intresting [15:26] that indicates that it breaks reaqlly really early [15:26] janimo: I thought it only had 512 [15:27] 868432 [15:27] bug 868432 [15:27] Launchpad bug 868432 in SchoolTool Gradebook "• one of Worksheets view or Worksheet's title edit view show unstranslated value " [High,Triaged] https://launchpad.net/bugs/868432 [15:27] ogra_: No, that was the amount of RAM on an mx53loco. :P [15:27] hmm [15:27] lol [15:28] NCommander, move ? [15:28] On my system, last time I tried an image it failed to load the panel and several other issues until I had a working swapfile. [15:28] Well, swap is back on again. [15:28] well, swap should be back [15:29] I'll test today's image in a bit. [15:30] [tpic] ARM Image Status (ogra, NCommander) [15:30] we [15:30] [topic] QA Status (GrueMaster, mahmoh) === meetingology changed the topic of #ubuntu-meeting to: QA Status (GrueMaster, mahmoh) [15:32] I have spent most of the week tracking down the banshee issue. I have ruled out possible SMP issues and for the most part, mono core and addons work from what I can tell by running other apps. [15:32] GrueMaster: anything tobring up [15:33] I have also been trying to get some feedback from banshee developers on the #banshee channel on irc.gnome.org. [15:33] Will continue on those tracks today. [15:33] k anything else? [15:33] Daily image for today just booted through oem-config for me (and there was much rejoicing). [15:34] Although there is a crash report I'll need to look at. === zz_bigbash is now known as bigbash [15:35] Is unity-2d supposed to use the same settings as Unity for hiding the panel? If so - fail. [15:35] crash appears to be oem-config. Maybe I'll have something useful to report on it.finally. [15:35] i think the default is "2" in dconf-editor [15:36] not sure which hide behavior that sets :P [15:36] but there should be a description in the editor [15:37] Ugh. Can't report crash on oem-config because libgtk2.0-0 is out of date. [15:37] There was no description in gconf-editor for that key. [15:37] dconf... [15:37] gconf is dead [15:37] At least none that I saw. [15:37] ok [15:37] Will look later. [15:38] if you still have gconf settings anywhere thats a bug [15:38] Nothing else here. [15:38] Once this new apt builds, I might spin a new set of images. [15:38] Installer performance will seem a bit snappier. [15:39] For a 6 minute period or so that update-apt-xapian-index isn't killing your SD in the background. :P [15:40] I would ask that everyone on the team with a working panda please try to do some testing with the daily desktop image. I am seeing too many crashes for a good release. [15:41] * ogra_ didnt see any in the last image he tested [15:41] that was a few days after beta [15:42] Hence why I said "daily". Beta was 2 weeks ago. [15:42] Oh, we need to get on ndec's case about the ti-omap-extras stuff actually existing for oneiric. [15:43] GrueMaster, yes, i tested a dail [15:43] y [15:43] as i said [15:43] a few days after ... [15:43] today's daily. A lot of packages have changed in the last two weeks. [15:43] sure === bigbash is now known as zz_bigbash [15:44] 6th Oct daily + morning dist-upgrade = ubiquity crash (at least here) [15:44] [topic] Linaro Updates (rsalveti) === meetingology changed the topic of #ubuntu-meeting to: Linaro Updates (rsalveti) [15:44] Just filed bug 869284. [15:44] Launchpad bug 869284 in geoclue (Ubuntu) "geoclue-master crashed with signal 5" [Undecided,New] https://launchpad.net/bugs/869284 [15:44] * rsalveti waves [15:44] i think i saw evan talk about that issue today [15:44] not much to report from the Linaro side this week, besides the planning for the 11.10 cycle [15:44] https://launchpad.net/linaro-ubuntu/+milestone/11.10 === beuno is now known as beuno-lunch [15:45] jcrigby pushed the fix for bug 867670 and bug 867650 [15:45] Launchpad bug 867670 in u-boot-linaro (Ubuntu) "OMAP 4460 based pandas run too hot at current operating point" [High,New] https://launchpad.net/bugs/867670 [15:45] Launchpad bug 867650 in u-boot-linaro (Ubuntu) "OMAP4 eMMC support is missing" [High,New] https://launchpad.net/bugs/867650 [15:45] but as SRU [15:45] still in progress [15:45] rsalveti, how is the move to oneiric going ? [15:46] rsalveti: I need to talk to him about that. [15:46] rsalveti: But the fixes he pushed looked entirely suitable for release. [15:46] ogra_: we're still blocked with bugs at the linaro-image-tools [15:46] :( [15:46] infinity: is it critical enough for the releasE? [15:46] ogra_: but we expect to have working images next week [15:47] we too :) [15:47] rsalveti: Did we not want 4460 to work with oneiric images? [15:47] I'll also make sure the unity3d packages are in place, so we can demonstrate it with oneiric + latest sgx packages [15:47] rsalveti: It's not like we're respinning images post-release. [15:47] * ogra_ hugs rsalveti [15:47] rsalveti, if you need me for PPA copying or anything, ping me [15:48] (for 3D) [15:48] infinity: yeah, there's one issue for 4460 that might be important for the release [15:48] ogra_: sure, I'll let you know when I get it all working [15:48] rsalveti: The overheating one, at least. But I thought I saw another. [15:48] but I should be able to have a PPA for that [15:48] rsalveti: Still, the installer setting your board on fire is bad enough. :P [15:48] infinity: yup :-) [15:48] infinity: let's talk about this at #ubuntu-arm then [15:48] rsalveti, well, they eventually need to end up in the ti ppa [15:49] meh. Self-heating. [15:49] ogra_: oh, that's fine by me, thought we would like a separated ppa for that [15:49] well, winter is near in the northern hemisphere ... probably the pandas know that ;) [15:49] once I have the packages all working I'll let you know, then we can make sure it lands at the proper ppa [15:49] * GrueMaster looks outside. Near? [15:49] rsalveti, well, whatever works, effectively panda is the only thing we can run it on atm [15:50] yeah [15:50] so it makes sense to put it in the TI one i think [15:51] sure, and it's already enabled by default once you installed the sgx drivers [15:51] :-) [15:51] right [15:51] that's all from my side [15:51] NCommander, move [15:52] next week I should have all the planning for connect/uds in place [15:52] at least from my side [15:52] NCommander, move ! [15:53] time is running out and we need to get the specs assigned [15:54] davidm, did you see the recent additions to the spec ideas page ? [15:54] * ogra_ gets the feeling he talks to an empty room [15:55] * rsalveti is still around, but not important anymore [15:55] ogra_, nope have not [15:55] I'll have a look [15:55] davidcalle, see the two smagoun buts at the bottom [15:55] that looks like linaro material [15:55] [topic blueprints === meetingology changed the topic of #ubuntu-meeting to: blueprints [15:56] so NCommander said he'd take all server specs and have them registered next week [15:56] [chair] ogra_ [15:56] Current chairs: NCommander ogra_ [15:56] infinity, are you taking the HF spec ? [15:56] * infinity looks. [15:56] since you do the work i guess ... [15:56] But I imagine I am. Didn't know there was one. :P [15:56] it just says armhf _) [15:57] Ahh. Kay. [15:57] Yeah, I'll take that. [15:57] * ogra_ still doesnt know what "linaro arm boot " is supposed to mean [15:57] davidm, can we skip that one until its clear what it means ? [15:58] then we have "ARM ISO install for non-mmc hardware" [15:58] Does smagoun realize that an emulated live-build is likely to be slower than the real thing? [15:58] who wants that ? i suspect its just d-i images [15:58] ogra_, I think that means 'arm boot speed' [15:58] infinity, i think he doesnt want qemu, they used it in the past [15:58] janimo, linaro arm boot ? [15:58] ogra_: He has to have qemu. [15:58] janimo, do you want to take it ? [15:58] ogra_, yes. I think so [15:59] ogra_: His packages won't magically install on x86. [15:59] and find out if thats true ? [15:59] ogra_, well it is a postponed one from O so I guess I'll do something related still [15:59] infinity, well, qemu-arm-static ... [15:59] ogra_: Still qemu. [15:59] janimo, a postponed one ? [15:59] ogra_: Anyhow, I should probably take smagoun's specs, so I can shoot them down as crack. [15:59] oh, yours [15:59] indeed [15:59] ogra_, yes [15:59] infinity, well, one is clearly linaro [16:00] infinity, unless smagoun is going to do the work [16:00] the package cross build stuff was already discussed art ubuntu-devel [16:00] which he apparently doesnt read, else he could have participated :) [16:01] davidm, do we expect achiang to work on the spec he proposed ? [16:01] i think he is oem [16:01] else one of us has to take the firefox elfhack one [16:02] I think our time's up. [16:02] well, that doesnt go anywhere here, lets adjourn, i'll assign specs that have no owner [16:02] * ogra_ thinks him holding monologues to the team with only infinity participating is a waste of time [16:02] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [16:02] Meeting ended Thu Oct 6 16:02:49 2011 UTC. [16:02] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-10-06-14.59.moin.txt [16:03] ogra_, is bug 803752 still going to land? [16:03] Launchpad bug 803752 in jasper-initramfs (Ubuntu Oneiric) "jasper needs to support preseed files " [High,Triaged] https://launchpad.net/bugs/803752 [16:03] skaet, nope, i thought i had closed it [16:03] * ogra_ does so now ... preseeding is supported, just not preseed files [16:03] ogra_, I hope achiang will step up if not likely the task will not get scheduled [16:04] k [16:04] ogra_ thanks. Also, what about ac100 tarball installer. [16:04] ? [16:04] just because there is an idea, no matter how good does not mean we do it. [16:04] bug 856278? [16:04] Launchpad bug 856278 in ac100-tarball-installer (Ubuntu Oneiric) "installation mode from SD card to USB key fails" [High,Triaged] https://launchpad.net/bugs/856278 [16:04] skaet, ?? what about it ?? [16:05] skaet, ah, thats a special case [16:05] :) [16:05] (sorry lagging here) [16:05] i can release note it, the majority of people installs to internal [16:06] fair enough. thanks, just trying to get my lists pared down. ;) === beuno-lunch is now known as beuno [17:58] o/ [17:58] * stgraber waves [17:59] * pitti says hello [18:01] seems the "chair: sabdfl" is obsolete, Mark already sent his apologies and he isn't an official board member any more anyway [18:02] seems the brainstorm review is now done, thanks cjwatson [18:02] http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2011-10-06-brainstorm-review.html [18:03] no community bugs either [18:03] I didn't see anything on the ML, did I miss something? [18:04] ARB [18:04] https://lists.ubuntu.com/archives/technical-board/2011-October/001100.html [18:04] is a new one [18:04] hey wendar [18:04] hi [18:04] #startmeeting [18:04] Meeting started Thu Oct 6 18:04:34 2011 UTC. The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [18:04] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [18:04] #topic recruiting new members for the ARB === meetingology changed the topic of #ubuntu-meeting to: recruiting new members for the ARB [18:05] I admit I haven't read it yet, shall we allow some minutes to read/digest it? [18:05] (release crunch, sorry0 [18:06] I've always found the lack of a requirement to be a developer troubling. [18:07] ScottK: "evidence of activity" isn't really as strong as _being_ a developer [18:08] I find that a bit troublesome as well; being able to spot problems in these packages requires at least some packaging experience [18:08] we've talked about that, in the current group, and generally assume that we will make it a requirement in the future, so for this cycle we looked for applicants who are Ubuntu developers [18:08] hopefully this will be ensured by the voting/application process, but perhaps it could be made explicit? that an applicant should at least be a PPU? [18:08] I find it particularly troubling given it's enabled in the default install. [18:10] pitti: member of ~ubuntu-dev should match all PPU/MOTU/Core-dev (unless we forgot to add some members to that team) [18:10] the only reason we haven't already made it a requirement, is that we're unsure how to handle the fact that half the current ARB aren't Ubuntu Developers, and we're already hurting for bodies [18:10] aside from that the proposal seems straightforward and clear to me [18:10] but, we could make it a requirement now, with a transition plan [18:11] wendar: is that becuase these members aren't generally interested in Ubuntu packaging? do they want to become ubuntu devs? [18:11] I certainly do :) [18:11] I'm pretty sure the other ARB member does too [18:12] how about making it policy now, but allow for existing members to be allowed with the stated intention that they are working towards dev? [18:12] I'm fine with that. [18:12] sounds good [18:12] the requirements to these packages are quite a bit different to 'ordinary' packages, with /opt and all that, but one should at least be familiar with packagign basics [18:13] kees: that sounds good; I certainly don't intend to invalidate the current board [18:14] so the proposal is [18:14] - Ubuntu membership [18:14] + https://launchpad.net/~ubuntu-dev membership [18:14] * kees nods [18:14] Is Ubuntu membership required for PPU? [18:14] stgraber: WDYT? [18:15] pitti: +1 [18:15] As long as Ubuntu membership is required for PPU, I think that's good. [18:16] ah, I'm fine with making that explicit and just have both requirements [18:16] ScottK: technically I think ubuntu membership is a consequence of being in ubuntu-dev [18:16] also, all 3 current applicants we (as in ARB) have on our list are members of ~ubuntu-dev [18:16] Hmm, i thought PPU was an avenue to get membership? [18:16] but I'm not entirely sure whether the DMB requires that as a prerequisite, or grants it together with PPU [18:16] (via ~ubuntu-dev?) [18:17] IIRC we (as in DMB this time) simply grant it by giving PPU === noy_ is now known as noy [18:17] that was my impression, too [18:17] Not a point worth spending a lot of time on then. [18:17] wendar: so, are you okay with adding ~ubuntu-dev membership as a requirement? [18:17] yup, reload the page [18:17] wendar: heh, says ~ubuntu-de [18:18] I'm afraid teaching everyone to speak German is a little too much effort [18:18] :) [18:18] edited again [18:18] thanks [18:18] #vote TB signoff of https://wiki.ubuntu.com/AppReviewBoard/Restaffing [18:18] Please vote on: TB signoff of https://wiki.ubuntu.com/AppReviewBoard/Restaffing [18:18] Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) [18:18] +1 [18:18] +1 received from pitti [18:18] +1 [18:18] +1 received from kees [18:19] stgraber: ? [18:19] +1 [18:19] +1 received from stgraber [18:20] we only have bare minimum quorum today, but my feeling is that this is pretty unanimous [18:20] (sorry, was looking through the list of ~ubuntumembers) [18:20] #endvote [18:20] Voting ended on: TB signoff of https://wiki.ubuntu.com/AppReviewBoard/Restaffing [18:20] Votes for:3 Votes against:0 Abstentions:0 [18:20] Motion carried [18:20] I'll reply on the TB list, and other TB members can then weigh in [18:20] wendar: thanks! [18:21] thanks all! [18:22] #topic next chair === meetingology changed the topic of #ubuntu-meeting to: next chair [18:22] we usually follow alphabetically, which would be soren [18:22] alphabetically? yup. [18:22] but as he hasn't been in any meeting yet, I propose that we skip him this time [18:22] stgraber: ready to chair the next one? :) [18:23] sure [18:23] stgraber: do you want to chair the next one? I can guide you to what to do after the meeting [18:23] pitti: that'd be great [18:23] heh [18:23] oh, these hundreds of hours on the typewriter and pasting stamps [18:23] #topic AOB === meetingology changed the topic of #ubuntu-meeting to: AOB [18:24] nothing else from me; stgraber, kees, wendar, ScottK? [18:24] Nope. [18:24] nope [18:24] nope [18:24] Not unless you want an off the cuff sru exception request [18:24] I'd like to keep uploading postifx bug fixes post-release, but didn't have time to prepare anything. [18:25] pitti: nothing from me [18:25] This is the upstream that says, "We don't have a bug tracker because we don't leave known issues unfixed." and does it. [18:25] ScottK: is there usually something in them which goes beyond a mere aggregation of individual "we want these" fixes? [18:26] #topic postgres SRUs === meetingology changed the topic of #ubuntu-meeting to: postgres SRUs [18:26] erk [18:26] #topic postfix SRUs === meetingology changed the topic of #ubuntu-meeting to: postfix SRUs [18:26] silly autofingers :) [18:26] Yes. There's two primary upstream developers who have a strong vision for the product. [18:26] Most bug reports turn into "Where in the documentation does it promise it's supposed to work that way?" [18:27] one thing that we need to fix there first are the eternal debconf questions on upgrade which potentially destroy your config (haven't checked, I always just say "no config") [18:27] So it's very strongly spec'ed. [18:27] Shouldn't lamont be in this discussion? [18:27] lamont and I have discussed it. [18:27] pitti: I don't recall those being an issue in a long time (I don't get the questions) [18:27] ScottK: so do you think the problem is that there are changes which are debatable, or that the problem is on the validation side? === noy_ is now known as noy [18:28] ScottK: oh, wow; maybe I should file a bug then, I get them everytime [18:28] Users have an expectation of how an MTA should work and they are often wrong. [18:29] Post-release, postfix sticks to not changing functionality based on it's extensive documentation. [18:29] They are very, very picky about it. [18:29] i. e. you want to establish a permanent microrelease exception for postfix? [18:30] Yes. [18:30] If they are happy with it, it is very safe for us. [18:30] I would support that [18:30] so I assume this is for not verifying all changes individually, but have a way to regression-test the entire update [18:30] Upstream regression tests the upstream code before releasing. [18:31] kees: how much coverage does the qa-regression-test bzr have for postfix? [18:31] I think we need to mostly make sure the packaging works and there's nothing major wrong. [18:31] pitti: it's fair, let me double check [18:31] we still need some amount of testing the actually installed package, to guard against misbuilds, packaging errors, etc. [18:31] pitti: every regression I have seen in a micro-release update of postfix has been introduced by the debian/ubuntu packaging [18:31] I've been backporting postfix for a long time and I've never had an issue. [18:31] lamont: yes, that's what I'm concerned about :) [18:31] ScottK: I've never had an issue with Wietse's work. my own is the only concern [18:32] we had the weirdest things in SRUs, no-change uploads breakign completely, and the like [18:32] That's generally obvious in the normal level of SRU testing we do. [18:32] pitti: fwiw, that has usually been me adding in my own other bugfixes and getting it wrong [18:32] when I just grab the latest upstream and stuff, it's always been beauty [18:32] pitti: mostly it tests authentication mechanisms and basic delivery/forwarding [18:32] My view is that if that works, it's 99.9% good. [18:32] kees: qa-regression bzr is integration testing on the actually installed .debs, right? [18:33] pitti: correct [18:33] kees: is there any existing wiki documentation how to run this? or do we need a special page for postfix? [18:33] pitti: it expects packages to be installed, but does its own configuration manipulations to attempt various auth methods and delivery methods [18:33] if we could just link to it on the MRE page, that'd be good [18:34] pitti: there is no general docs on running the tests, no, but there is a pretty common methodology to it, and each test is documented on how to run it in the header comments [18:34] I've never had a problem figuring them out from the comments. [18:34] I'm using postfix both on server as well as on my workstations, and never really had a problem with it except those annoying debconf prompts, I'm fairly convinced of its quality [18:34] kees: right, I mostly mean where to get it, how to run it, etc. [18:34] as long as the proposer of the SRU (lamont/ScottK) know how to run it, it's fine for me [18:35] lamont, ScottK: ^ do you? [18:35] I know how to tell ScottK to run it. [18:35] http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-postfix.py [18:35] I didn't run the postfix one before, but I run the clamav one all the time. [18:35] I'm sure it's not an issue. [18:35] my gut feeling is that an MRE is fine, provided that validation entails running the upstream regression tests (which already is done by upstream), and the existing integration tests [18:35] lamont: delegation FTW! [18:36] pitti: to be fair, my normal approach to postfix is to take the latest upstream, build it, install it, send email, and upload. If I actually do any work, that's when I get all pedantic about testing it, ever since I broke it that one time [18:36] ScottK: is there a pending microrelease which we would SRU? [18:37] yes. [18:37] There's a backports request pending that we'd direct at -proposed instead. [18:37] so perhaps we could do this as a model case, see how much changes these carry, and how validation works, etc. [18:37] * kees nods [18:37] sounds good [18:38] but in general I'm fine with this proposal; upstream's stable policy and regression testing is certainly appropriate for our SRU criteria [18:38] It would be -proposed for natty only. [18:38] Lucid/Maverick released with 2.7, so those will still go to backports. [18:38] ah, no 2.7.x updates any more? [18:39] There are some of those I'll need to go back and look at too. [18:39] then I'm even less concerned [18:39] most postfixes which really matter certainly run on LTSes [18:39] No, we can do them too, just referring to the current backport request. [18:39] but doing this on natty now gives us a nice trial period for precise [18:39] So we'd keep 2.7 up to date in -proposed for lucid and 2.8 in backports. [18:41] ScottK: can we try that SRU once, and when it's done, come back to TB and discuss the general MRE when we all have more experience how that worked? [18:41] OK. [18:42] I'm sure it will be okay, but I'm a bit uncomfortable with saying "+1" before seeing it in action [18:42] might just be me being a wimp, of course [18:42] kees, stgraber: WDYT? [18:42] right, I prefer SRU history, then MRE [18:43] I'm signing up for reviewing that SRU [18:43] but this looks to be a good trajectory [18:43] I'm fine with this. [18:43] nice [18:43] trying with one SRU osunds good [18:44] *sounds [18:44] #topic AOB === meetingology changed the topic of #ubuntu-meeting to: AOB [18:45] going once.. [18:45] going twice.. [18:45] sold! [18:45] thanks everyone, have a good night! [18:46] thanks pitti! [18:46] will send notes / update report. etc. now [18:46] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [18:46] Meeting ended Thu Oct 6 18:46:12 2011 UTC. [18:46] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-10-06-18.04.moin.txt [18:46] wow, nice report [18:47] thanks pitti! === ayan_ is now known as ayan === zz_bigbash is now known as bigbash