=== yofel_ is now known as yofel
=== lifeless_ is now known as lifeless
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== dyfet is now known as dyfet_away
davidmG'day NCommander14:00
MootBotMeeting started at 08:01. The chair is NCommander.14:01
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]14:01
ogra*sigh even14:01
ograseems we have no logs from last meeting14:01
NCommanderogra: ?14:02
ograand dyfet_away didnt add the action items14:02
* NCommander sighs14:02
ograwe had some i'm sure14:02
ograi created https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100713 but indeed its empty14:02
NCommanderI got the raw log14:03
NCommander[topic] Action Item Review14:04
MootBotNew Topic:  Action Item Review14:04
ograACTION received:  openjdk status (dyfet)14:04
ogra ACTION received:  md5sums and manifests for daily images (NCommander)14:04
NCommander[topic] dyfet to work on openjdk FTBFS14:04
MootBotNew Topic:  dyfet to work on openjdk FTBFS14:04
ograthats it14:04
ogragoing through my local logs14:04
NCommanderogra: I got them :-)14:04
ograah, cool14:04
NCommanderno dyfet_away14:05
* NCommander sighs14:05
NCommandermd5sums and manifests for daily images14:05
NCommanderc/o. probably won't get this until the sprint14:05
ogramanifests are stored next to the ext3 fs14:05
ograso that should be trivial14:05
ogramd5sums will be harder :)14:05
NCommanderogra: it is, I just need a little time to do it:-)14:05
ograno hurry14:06
ograthe bug is A3 targeted14:06
ograworst case do it at the sprint :)14:06
NCommander[topic] Current Items14:06
MootBotNew Topic:  Current Items14:06
NCommander[link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html14:06
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html14:06
NCommander[link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html14:07
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html14:07
ograone done14:07
NCommandermy spec still isn't showing up14:07
ograeven though i was inclined to set it back to TODO14:07
rsalvetihe moved the fuseext2 doc to TODO again14:08
ograi did14:08
NCommanderfuseext2 is marked as unstable, why are we using it?14:08
rsalvetioh :-)14:08
ograand the other one isnt DONE either14:08
ograi would at least expect the bug number mentioned somewhere and asked for that14:08
rsalvetiNCommander: for ro only I believe it works well, the problem is rw14:08
ogra(the DNOE item is about filing an upstream bug)14:09
rsalvetibut dyfet_away still needs to test it better to find the best options14:09
ograand need to document better14:09
ograi added some comments and talked to him this morning14:09
ograanyway, all other specs are full TODO14:09
ogranothing DONE yet14:09
NCommanderogra: how can we get improved subarch on this list?14:10
ograi pinged ted about the lightweight panel but he said he has no usable code yet14:10
ograNCommander, is it properly milestoned now ?14:10
ograthen it should show up automatically14:10
NCommanderogra: I thought it got fixed14:10
NCommanderI'll lookat it again14:10
ograMilestone target:14:10
NCommander[topic] Kernel Status (cooloney, mpoirier)14:10
MootBotNew Topic:  Kernel Status (cooloney, mpoirier)14:10
ograstill not milestoned14:10
ogra[topic] Kernel Status (cooloney, mpoirier, lag)14:11
mpoirierfinally done with https://bugs.launchpad.net/bugs/59438214:11
ubottuLaunchpad bug 594382 in linux (Ubuntu Maverick) "Wake up daisy chain activation failed on omap3" [Critical,Fix released]14:11
* ogra extra added lag to the list on the wikipage14:11
ogrampoirier, sweet14:11
mpoirierthis is now fix and done with.14:11
ubottuLaunchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) "DSS2 oops when shutting down while DPMS is active" [Medium,Confirmed]14:11
mpoirierdss2 oops when rebooting14:11
mpoirierseem harder to reproduce.14:12
mpoirierthis is next on the list.14:12
mpoirierSDHC card is still very present.14:12
lagI'm assuming you don't want updating on every bug?14:12
ogrampoirier, just wait until the monitor turns off and issue a shutdown or reboot via ssh14:12
ogralag, no, just an overall status is fine14:12
ograand bugs that you really care about to let us know14:12
mpoirierogra: let's touch base after.14:12
mpoiriermpoirier: done with status.14:13
lagmpoirier: When you've finished type ".."14:13
NCommander[topic] QA Status (GrueMaster)14:13
MootBotNew Topic:  QA Status (GrueMaster)14:13
GrueMasterNot much to report.  Image builds are currently broken.  Last image was 7/7.14:14
ogranot true14:14
ograi really should add you to the build reporting :P14:14
ogralast image is last nights build14:14
MootBotLINK received:  http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100713/14:15
GrueMasterlast "tested" image was 7/7.  Since my day hasn't officially started yet...14:15
NCommandercan I go on?14:16
ograany special bugs you want to point out ?14:17
GrueMasterat any rate, I have been focusing on various different aspects of getting my panda somewhat stable, trying to reproduce some failures and getting stable enough to report some bugs.14:17
ograGrueMaster, if you cant use apport, just file them otherwise14:17
ogra(unless they are kernel bugs, i know they are a bit more strict)14:17
ograi really dont care how image related bugs are filed :)14:18
NCommander[action] NCommander to unbreak apport retracer14:18
MootBotACTION received:  NCommander to unbreak apport retracer14:18
ograis it broken ?14:18
* ogra doesnt even notice14:18
GrueMasterI have a workaround for the parport_pc driver oops, and have documented it in the bug I filed against it.14:18
ograi think lag works on that one on the kernel side too14:18
lagI do14:18
lagI have sent a patch upstream14:18
lagGrueMaster: I didn't get a message?14:19
GrueMasterbug 60306214:19
ubottuLaunchpad bug 603062 in linux-ti-omap4 (Ubuntu Maverick) "oops in parport_pc_probe_port function of parport_pc module (dup-of: 601226)" [Medium,New] https://launchpad.net/bugs/60306214:19
ubottuLaunchpad bug 601226 in linux-ti-omap4 (Ubuntu Maverick) "Unable to handle kernel NULL pointer dereference in ppdev module" [Medium,Triaged] https://launchpad.net/bugs/60122614:19
lagOh, the blacklist thing?14:20
lagYes, okay14:20
GrueMasterActually, bug 60122614:20
lagThe true fix should be out soon enough14:20
* lag crosses his fingers14:20
* GrueMaster needs coffee still.14:20
GrueMasterOther than that, I have tested the fix for the daisy chain issue.  Seems to have gone away.14:22
ograwell, for the true fix we need another linux upload14:22
ograi dont think the commit was uploaded yet14:22
ograso wait with cheering :)14:23
ogracurrent binary has still the A2 workaround14:23
GrueMasterNothing else to report at this time.14:24
ograNCommander, oh, wasnt there a c/o for asac from two meetings ago ?14:24
NCommanderogra: possibly14:25
* ogra just remembered that qt upstream conversation thing14:25
NCommander[topic] ARM Porting/FTBFS status (NCommander, dyfet)14:25
MootBotNew Topic:  ARM Porting/FTBFS status (NCommander, dyfet)14:25
ograi commented on dyfet_away's apr bug14:25
NCommanderogra: oh, that.that requires anoffline conversation until we can bring it back here14:25
ograhis patch changes a strin thats unecessary14:25
ograif thats fixed i'll upload apr for him14:25
NCommander[action] NCommander and asac to discuss qt qreal issue14:25
MootBotACTION received:  NCommander and asac to discuss qt qreal issue14:25
ograbeyond that openjdk causes more and more fallout14:26
NCommanderogra: huh?, that was a buildd sucking issue14:26
ograNCommander, what ?14:26
NCommanderit builds properly locally14:26
NCommanderogra: apr builds fine without modification expect on the buildds14:26
ograits a glibc issue as i understood lool14:26
ograand a bug against glibc is filed14:27
* NCommander looks at the log14:27
asacNCommander: did you manage to talk to thiago at akademy about the soname (for qreal)?14:27
NCommanderasac: I did, hence the part where we need to talk :-)14:27
NCommanderasac: there are some points I need to work out with you, and I don't want to derail the meeting with them until we have a chance to compare notes14:28
ograso the qt4-x11 ftbfs is the same issue i guess ?14:28
ograwhich tears down kde again14:28
asacNCommander: ok cool. catch me tomorrow14:28
NCommanderogra: qt4-x11 is an ICE14:29
ograoh, right14:29
NCommanderogra: and kdebindings is FTBFS still (though I know why its FTBFS (someone removed the support code to make ARM work))14:29
ograwell, wouldnt the upstream fix change that ?14:29
NCommanderogra: your assuming I've made the change upstream yet :-)14:30
ograi'm not assuming anything :)14:30
ograthus the question mark above14:30
NCommanderogra: once I commit the change upstream, w'ell suck it into the next upload of KDE. The problem is that with the constant travel, I haven't had a board setup long enough in one place to actuall do all the builds I need to14:31
ograyeah, all fine, no need for excuses :)14:32
NCommanderogra: heh14:32
NCommander[topic] ARM Image Status (ogra, NCommander)14:32
MootBotNew Topic:  ARM Image Status (ogra, NCommander)14:32
ograwe have images !14:33
NCommanderthey exist.14:33
* NCommander ducks14:33
ograstill lots of small glitches etc14:33
ograbut they generally work14:33
ograi'd indeed appreciate more testing and bug reports14:33
NCommanderogra: looks like our preinstalled image support code works nicely14:34
NCommanderogra: got anything else to add?14:34
ograwell, i'D like to see more SD crads being tested14:35
GrueMasterHow many more?  I have 4.14:35
ograand i'm currently experimenting with a progressbar for resizing14:35
rsalvetiI'll also help with testing when I get my boards14:35
ograrsalveti, that was a secret hint for NCommander  :)14:35
ograto also test on his board14:35
rsalvetiogra: nice, progress bar is always good :-)14:36
ograrsalveti, i know you will test once you have the HW :)14:36
ograyeah, i just found that resize2fs has a -p option14:36
ograjust need to test how to translate that to plymouth14:36
ograor at least to a text mode14:36
NCommanderogra: fun with pipes?14:36
ograyeah, something like that14:37
ograand screen scraping or so14:37
NCommanderogra: you may just want to patch resize2fs to actually do something like the fsck -F option worse case scenario14:37
ograwell, i havent seen the progressbar yet14:37
ograi'm still playing with the code atm14:38
ograpossible that its sufficient14:38
ograanyway, nothing else about images14:38
NCommander[topic] Any Other Business14:38
MootBotNew Topic:  Any Other Business14:38
rsalvetiI can talk about the rootstock stuff now14:38
* NCommander points at the blank weekly reports section of the meeting from last week14:38
GrueMasterWill there be a meeting next week during the sprint?14:39
NCommanderGrueMaster: nope14:39
rsalvetiI finally got an image created as user, and posted my branch at https://code.edge.launchpad.net/~rsalveti/project-rootstock/no-root14:39
rsalvetiogra: can you take a look later?14:39
ograNCommander, can you add a rootstock section to the agenda for next meeting =14:39
ograNCommander, so rsalveti has his own slot14:39
rsalvetiogra: yeah, that would help14:39
ograrsalveti, will do14:40
rsalvetihad some issues with qemu, fuseext2 and genext2fs14:40
rsalvetibut after finding the correct options, I just got the qemu bug14:40
ografusext2 was supposed to be researched by dyfet_away14:40
ubottuLaunchpad bug 604872 in qemu-kvm (Ubuntu) "qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm" [Undecided,New]14:40
rsalvetimost of the time I get a seg fault on it =\14:41
rsalvetiso I created a workaround at rootstock code, to run the vm more than one time14:41
rsalvetiand with that I'm able to create the rootfs most of the time14:41
rsalvetiso now I'll wait ogra review, finish it and move to the other rootstock bugs and patches14:41
ogradid you test the rootfs afterwards ?14:42
rsalvetiand I'm running the image at my b5 beagleboard :-)14:42
ograto make sure the crash doesnt cause breakage in the image14:43
rsalvetiogra: yeah, did run quite fine, at least the almost 10 times I tested14:43
rsalvetibecause the seg fault happens just after the debootstrap second stage14:43
rsalvetiprobably when mounting proc or sysfs14:43
rsalvetiso I'm now checking if the bootstrap script is there on the installer script, and if not just continue14:44
rsalvetiand at the end you'll get the image14:44
ogratry to add some schos in the installer script so you can see the exact point14:44
rsalvetiogra: yep, quite strange14:44
rsalvetiogra: I did this, and even the echo got the seg fault some times14:44
rsalvetiit seems that the debootstrap lets qemu in an unstable situation14:45
ograi wonder if its a kernel issue of the vm kernel14:45
ograwould require some qemu testing with an image14:45
rsalvetiogra: I'd also like to test a different kernel to see if this could be the issue14:45
rsalvetibut still needs to find/build another one14:45
rsalvetibut that's all from my side14:47
NCommanderok, I think I can close the meeting14:48
NCommanderany objections?14:48
ogracount down :)14:48
MootBotMeeting finished at 08:49.14:49
dyfet_awayoh wow got back from doctor just in time for the end :(14:49
=== dyfet_away is now known as dyfet
cjwatsonno Keybuk?15:02
mdzhaven't seen him15:03
tgardnerI just received an email from him a bit ago15:03
cjwatsonI've SMSed him15:03
tgardner20 minutes ago15:03
cjwatsonhe's buried in something else; another volunteer to chair?15:04
cjwatsonis sabdfl going to be here?15:04
mdzassume no15:06
* pitti is in a mumble meeting as well, so hard for me to chair right now15:06
mdzmy previous call is running over as well15:06
cjwatsonmdz: can we just shunt forward a fortnight in the cycle, which would make it your turn to chair?15:06
mdzI looked at the agenda yesterday and it didn't appear to have been touched since the last meeting15:06
cjwatsonI added two items to it yesterday15:06
cjwatsonand there was already one from jono15:07
mdzI added the jono one when I looked15:07
mdzbut he's on holiday today anyway15:07
pittijono said he's on vac today15:07
cjwatsonok, I'll chair sisnce nobody else seems to want to15:07
MootBotMeeting started at 09:07. The chair is cjwatson.15:07
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]15:07
cjwatson[TOPIC] Action review15:07
MootBotNew Topic:  Action review15:07
cjwatsonof the items from two meetings ago, the only one not done was15:08
cjwatsoncjwatson to write up 2010-06-15 minutes15:08
cjwatsonI did that yesterday15:08
cjwatsonfrom last meeting:15:08
cjwatsonkees to check up on 174375 with bdmurray15:08
keesI've been talking with him about that; it's under way.15:08
cjwatsonmdz to follow up with doko on toolchain, ix86 performance15:08
cjwatsonkees: do we need to keep it on our agenda?15:09
keesthey're discussing the bug at the LP sprint, so it will likely turn into a real plan soon15:09
keescjwatson: probably not; I'll keep it moving with the LP team.15:09
cjwatsonmdz: any word from doko?15:10
mdzcjwatson: yes, he replied to t-b@15:10
mdzin fact I think this action was closed at the last meeting15:10
cjwatsonReview PostReleaseApps/Process (jono)15:11
cjwatson[TOPIC] Review PostReleaseApps/Process (jono)15:11
dokotest results and fixes are there, we should be ready to switch, but maybe lets discuss this on Mon15:11
MootBotNew Topic:  Review PostReleaseApps/Process (jono)15:11
cjwatsondo we want to discuss this today, given that jono is away?  he sent mail asking for feedback, I don't see any on the list15:12
mdzI've been involved with reviewing it already15:12
mdzso I've already given my feedback and it's been mostly incorporated I think15:12
cjwatsonI confess that I am not yet ready to vote on it15:13
pittime neither, I'm afraid15:13
mdzactions to review by next meeting?15:13
pittiI'll put it to my TODO list to review it by next meeting15:13
cjwatsonand perhaps to vote by e-mail15:13
cjwatsonI'll take an action to review and chivvy15:13
pittiemail vote WFM, too15:13
cjwatson[ACTION] cjwatson to drive review/vote on PostReleaseApps/Process15:13
MootBotACTION received:  cjwatson to drive review/vote on PostReleaseApps/Process15:13
cjwatsonlet's move on, my apologies for not being better prepared there15:14
cjwatson[TOPIC] Karmic kernel packaging changes (cjwatson)15:14
MootBotNew Topic:  Karmic kernel packaging changes (cjwatson)15:14
cjwatsonI invited kernel folks here today to discuss this; I see tgardner and smb15:14
smbI am here15:14
tgardnerhere is the discussion link: https://lists.ubuntu.com/archives/kernel-team/2010-July/011545.html15:14
mdzwelcome, kernel folks15:15
cjwatsonI was just about to start typing a summary; thanks for saving me the effort. :)15:15
pittismb: the other day we talked about providing a more stripped down diff which filters out the renames; is that available somewhere?15:15
cjwatsonmy response when asked to approve this by the kernel team was that I felt that it was explicitly outside the remit of what I was allowed to approve as an SRU team member15:15
smbpitti, I thought you were on cc of that email apw sent15:16
cjwatsonI advised that the TB would be the appropriate body to take a decision15:16
mdzI think I recall the previous iteration of this discussion15:16
mdzwhere there was a question about whether substantial packaging changes were OK for SRU15:16
pittismb: I was CC'ed to a thread, yes; but I didn't see a filtered patch?15:16
smbpitti, Ok, I might resend it15:16
mdzI believe I took the position that if the resulting .debs were equivalent (easy to confirm), and everything built OK on all architectures, there were cases where this was appropriate to do15:17
smbpitti, There was a diff inlined15:17
pittimy concern is that whatever the potential benefit is, ensuring that all packages still are built the same way on all arches, and rule out weird race conditions, compiler flags, etc., is very very expensive15:17
mdzi.e. the most important aspects of the packaging can be tested for correctness15:17
cjwatsonin general, we reject substantial packaging changes from SRUs.  However, I realise that the kernel is arguably a special case here given the extent of maintenance and number of complex packages involved.  What I don't want is for this to turn into a precedent for other packages, because then the floodgates open wide15:17
tgardnermdz, that has been my philosophy15:17
pittiand I can't vouch for that, so I don't feel like putting my approval stamp on it TBH15:17
mdzI have not seen any of the proposed changes in this case, so I can't comment on what the risks are15:18
tgardnerpitti, these packaging changes won't affect compiler flags.15:18
mdzthat link doesn't seem to have information on the actual code changes15:18
smbpitti, Though most if not all changes are outside the upstream kernel build infrastructure, so bulding itself would not be affected15:18
mdze.g. a debdiff15:18
pittismb: ah no, I didn't get a mail from apw, I was just on tgardner's thread15:18
cjwatsonI can produce a debdiff given a moment15:18
smbOur test was to debdiff all binary packages to see those contain the same files15:19
MootBotLINK received:  http://launchpadlibrarian.net/50067689/linux_2.6.31-21.59_2.6.31-22.61.diff.gz15:19
tgardnerthe debdiff is large because of the number of renames. what I'd like to do is to produce before and after packages and show that they are identical.15:19
cjwatsonI am curious what changes the kernel team would feel to be unacceptable in packaging15:20
tgardnerI guess changes that affected the content of the binary packages produced?15:20
tgardnerdoes that make sense?15:21
smbpitti, forward just sent to you kees cjwatson mdz15:21
mdzsmb: thanks15:21
mdzif it's possible to get a bzr-style diff which doesn't exaggerate the amount of change due to renames, that would be ideal15:22
tgardnermdz, we'd have to work on that, so not likely by the end of this meeting.15:22
cjwatsonexcept these changes do seem to affect the content in certain ways, for example linux-image-debug -> dbgsym15:22
smbmdz, I am not sure we can provide bzr style, but the mail forwarded contains hints about similarity15:23
mdztgardner: that's OK; I think the TB should be concerned with the general principle here, rather than this specific changeset15:23
tgardnerI'd also like to point out tat we intend to do this for Hardy (eventually)15:23
apwi believe the email smb just forwarded has the git diff which has the renames in it15:23
mdzhmm, package renames could be problematic15:23
smbmdz, not package renames15:23
smbmdz, renamed fieles in the infrastructure15:23
cjwatsonlinux-image-debug (-> dbgsym) ends up on ddebs.ubuntu.com rather than in the archive15:23
cjwatson-Package: linux-image-debug-2.6.31-21-generic15:24
cjwatson+Package: linux-image-2.6.31-22-generic-dbgsym15:24
apwcjwatson, though the current implementation is also pushing those over to ddebs15:24
smbcjwatson, Ok, that is a change that we were actually asked to do15:24
cjwatsonapw: what I'm trying to get at is the truth15:24
cjwatsonI'm being told "no changes in the content of the binary packages" <small>except for this one</small>15:24
pittiright, that ddeb rename is fine15:24
cjwatsonwhich other ones are we missing? :-)15:24
smbno package other than ddebs afaik. apw?15:25
cjwatsonI don't have a problem with that particular change given that pitti is the ddeb-meister and asked for it15:25
pittiso if all the changes don't affect the contents and don't affect the build flags, why do we have to put them into an SRU in the first place?15:25
apwcjwatson, after hardy those packages have always gone to ddebs regardless of names, the first is bodged specifically as i understands things15:25
cjwatsonapw: that's sort of beside my point; I'm trying to ask which other content changes are in there, given that it's clearly not zero15:26
smbpitti, The main reason is that builds have evolved into being the same but sometimes with slight differences15:26
smband those differences are error prone15:26
smbespecially as Lucid arm trees are based on Karmic kernel versions15:26
apwcjwatson, yep i get your point, and am trying to work out how to answer your question without making things less clear15:27
pittiif there are helper scripts in there which are mainly interesting for git maintenance etc., then they could be removed from the packaging altogether?15:27
smbSo the goal was to have one build infrastructure that we can get eventually to be applied to all releases15:27
tgardnersmb means with each release we've accumulated some cruft, and now we're trying to fix some of that cruft.15:27
pittieven if we figure out the changes this time, we'll have this conversation all over again the next time we update the packaging from trunk to stables15:27
cjwatsonnobody else gets to update their cruft in stable releases, though; what the TB needs to consider is why the kernel is different15:28
mdzpitti: right, hence my feeling that we should focus on the general principle instead15:28
apwthe update commit contains a changelog fragment u15:28
mdzand provide some guidance to the SRU team on how to handle situations like this15:28
pittiand given that karmic isn't LTS and 8 months old, it should not get that much changes any more15:28
apwindicating which changes are carried over15:28
tgardnercjwatson, because we have a dozen (or more) source code packages?15:28
mdzI don't see anything kernel-specific here, except insofar as the kernel happens to be one of the packages which sees the most change in stable15:28
cjwatsonfor the record, I object less to this if the TB approves it; what I really objected to was feeling like I was being leant on by management to approve something explicitly contrary to the policy I've been instructed to uphold15:29
cjwatsonso I want to go through the proper process15:29
mdzthat sounds reasonable enough15:30
mdzso the question here is, under what circumstances should substantive packaging changes be permissible in SRU?15:30
mdz(if any)15:30
smbProbably a big difference to other packages is that we carry several other packages (arm, ec2) which are based on the main repo and depend on a common infrastucture to be maintainable15:30
keesas far as compiler flags, etc -- both old an new packages could be rebuilt with V=1 and the build logs compared...15:30
mdzkees: unless they compile in parallel, of course15:31
smbwhich we do15:31
apwthough a sort could fix any ordering constraints on the results15:31
keesmdz: the security team has tools that handle that comparison pretty well.15:31
mdzkees: oh, neat15:31
cjwatsonmdz: IMO, aside from risk management, there has to be a pressing need - that is, the risk of making the change has to be less than the risk of not making it, in terms of maintainability constraints etc.15:31
mdzkees: share :-)15:31
cjwatsonthe kernel team is saying, AIUI, that the error rate from not having their substantive packaging changes is riskier than leaving things as they are15:32
cjwatsonI can respect that position, but I would like not to be put in the position where 100 other maintainers show up asking for similar things15:32
* smb nods15:32
cjwatsonbecause we won't be able to cope15:32
keesmdz: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head:/build-tools/diff-reorder15:33
mdzI think that if the changes can be verified to be true refactorings (i.e. not introducing changes to the binary packages), and the team responsible for maintenance feels the payoff is worth it, we should be open to that15:33
cjwatsonperhaps, for the time being, we should simply limit this explicitly to the kernel, with a rationale15:34
mdzif we set some guidelines, I think that would keep the floodgates closed15:34
cjwatsonI don't want it to be an option advertised for everyone to use15:34
kees(with http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head:/build-tools/buildlog-compare)15:34
pitticjwatson: me neither15:34
cjwatsonit's perhaps also worth noting that the kernel is one of the biggest users of stable updates15:34
smbI think there isn't any package being that complex either15:35
keesfirefox falls into this category too ...15:35
cjwatsonsmb: you'd be surprised ...15:35
pittiand we already are a lot less strict with kernel changes than for other SRUs, so in practice it's already special15:35
cjwatson(along with the desktop, but they generally don't update packaging)15:35
keesbut it's doing even larger updates15:35
cjwatsonthe rationale for firefox is, similarly, that the risk of not doing so is greater15:35
cjwatsonmore or less15:35
* kees nods15:36
mdzcjwatson: a decision on the kernel in general would be better than deciding on this change specifically15:36
mdzbut it doesn't smell right15:36
cjwatsonthe change, or the approach?15:37
mdzthe approach15:37
mdzif there are reasons why the kernel warrants such an exception, it should apply to other packages which have the same reasons15:37
mdzand if we don't agree on what those reasons are, the kernel shouldn't get an exception just because it's the kernel15:38
mdzthe idea of the kernel having looser change control, while being one of our most critical components, gives me the willies15:38
mdz(especially when pitti says that this is already the case in practice)15:38
tgardnermdz, don't forget that is kernel(s), not just the one. there are a bunch of them we're producing.15:39
cjwatsonthe bar certainly needs to be set high; it's vital that the SRU team has the ability to say no, otherwise we're just a rubber-stamp bureau and what's the point15:39
mdzyes, and I accept that when there is a lot of divergence in the packaging, this increases the risk of mistakes being made in updates15:39
mdzhas the SRU team said no to this?15:39
pittithe scope of code changes has been discussed several times as well, but I think eventually the SRU team just started to swallow them as they come in15:39
mdzis this an appeal, or a request for guidance?15:39
cjwatsonI said no, and that the kernel team could appeal to the TB15:40
mdzI see15:40
cjwatsonspecifically I said no because I felt that it was outside my range of permitted discretion15:40
cjwatsonmore perhaps than because I thought it was intrinsically wrong15:40
tgardnerI contend that it'll reduce the number of mistakes we might make if packaging is common across all of the kernel branches.15:40
pittisame for me; with the diff just sent it's a lot easier to review, but when I saw it the first time there was no way for me to say "yes, this is ok:15:40
mdzthe diffstat from apw looks pretty manageable15:41
pittiwith the renamings it's a little easier, but still a "{debian.master => debian}/rules.d/0-common-vars.mk" doesn't say muc15:41
pittisince it puts a previously inert file into action15:41
cjwatsonso reasons I can think of why the kernel is special:15:42
cjwatson * high flow of changes through updates15:42
cjwatson * many different packages synchronised across multiple releases15:42
cjwatson * significant degree of autogeneration in packaging15:42
cjwatson(in terms of rationale for the change, not in terms of the change itself)15:42
cjwatsonwhat else?15:42
pitti"many maintainers" perhaps?15:42
apwpitti, actually it moves a file which the reference also changes from the old to the new15:42
cjwatsonI don't know of any other packages meeting those descriptions right now15:42
mdzcjwatson: I'd say specifically a high flow of changes across multiple releases15:42
pitti"training new maintainers on the packaging"15:42
apw"multiple versions in each release"15:43
smbpitti, Oh yeah. Good one as well15:43
cjwatson(BTW I also said that I'd abstain in a vote on this since I was involved in the initial, er, full and frank debate)15:43
mdzcjwatson: I think we need to establish what the question is that we're voting on15:43
mdzif it's "does the SRU team have the authority to decide this?" then that is an easy yes15:44
mdzso if you said "no" on the grounds that you felt it was beyond the SRU team's mandate to decide, maybe we can address that governance issue rather than the technical question here15:44
mdz(easy yes - for me)15:45
cjwatsonthe precedent is that the SRU team does not have authority to make big changes to the SRU policy itself; that's why previous changes to that policy have been brought to the TB15:45
cjwatsonsuch as the micro-release exceptions stuff15:45
pittiI had thought it was "extend the SRU policy to allow repackaging for the kernel"?15:45
cjwatsonpitti: *nod*15:45
smbpitti, Actually not repackaging but change the build infrastructure as an SRU15:45
cjwatsonSRU policy changes have always gone to the TB before15:45
cjwatsonsmb: the wide term for this in the distribution is repackaging15:46
cjwatson(when the changes are this substantial)15:46
cjwatsonbut if you feel the term is emotive, we can choose a different one15:46
pittismb: right, I consider the build infrastructure part of the packaging15:46
pittibut calling it "change build system" WFM15:47
smbNo, I probably just had a different understanding of packaging15:47
cjwatsonpackaging> stuff under debian/15:47
cjwatsonwell, debian*/ in your case :)15:47
smbRight: :)15:47
smbI can live with that15:47
cjwatsonI'd like a straw-poll to check that the board in general, well, isn't implacably opposed to this change15:48
mdzI would be happy to support amending the SRU policy to say that repackaging is discouraged in general (for specified reasons), but the SRU team has the authority to make exceptions to this if the risk is bounded, and offset by the maintenance benefits15:48
cjwatsonI'm willing to draft such a policy if the board feels that it would support it15:49
pittiit would basically mean to put the SRU review into "blind mode" though15:49
keesI would support it if it included the "why the kernel is special" list as part of the guidelines for what makes an exception15:49
mdzI agree with cjwatson that we don't want to open this up generally15:49
pittiso we need to see if that's considered acceptable15:49
cjwatsonpitti: "blind mode"> could you expand on that?15:50
mdzpitti: why?15:50
smbpitti, Probably requiring some defined guidlines on what is required to provide as test that this changes are acceptable15:50
pittiI can't look at the delta and confirm that the changes are safe and don't introduce regression potential15:50
mdzpitti: don't you, in some cases, rely on other sources of information (such as testing) to confirm that changes are safe?15:51
cjwatsonI'm not accusing the kernel team of being malicious here; I'm happy to take them at their word when they present things like debdiffs of the completed binary packages, provided that we can still use our judgement on that evidence15:51
apwpitti, we have generally looked at packaging changes as 'trivially testable' in that if the binary packages are the same before and after this change then they are benign15:51
pittithe large majority of SRUs just add a small patch or a small packaging fix (dependencies, etc.) and are rather easy to review; a not too small number are upstream microversion updates, where we usually filter out the autoconf noise and review the rest15:51
apwcjwatson, and from our side we are more than willing to do whatever we need to to make your team comfortable15:51
pittiapw: that won't spot compiler flags, configuration changes, or weird linker errors, though15:52
apwknowing that you cannot understand the packaging at the level of detail that we might15:52
pittiso while a binary debdiff is important, it's not really sufficient15:52
cjwatsonkees' toolset for log comparison ought to help15:52
apwpitti, if any of those were different its not clear how the binaries could be identicle15:52
keesit's not perfect, but it helps.15:52
pittiso, I'm not saying that I totally oppose to what I called "blind mode" above, but we need to be aware of the fact15:52
mdzpitti: if it were possible to break this change up into smaller chunks, each of which was easier to review, and which didn't change the package output, would that make it acceptable to you?15:52
apwpitti, in the comparisons i did when doing the changes in later releases they had the same md5sum15:52
cjwatsongiven general authorisation from the TB to do this at all, I think that I would be willing to accept a comparison of binary metadata, binary file lists, and build logs on all architectures15:53
mdzpitti: in the kernel case, the configuration does get bundled into the package, so a binary debdiff would catch that, no?15:53
cjwatsonand trust to testing to catch errors beyond that15:53
pittiapw: comparing build logs with kees script plus binary debdiff together sounds rather safe, WDYT?15:53
mdzI agree15:53
pittimdz: oh, how so?15:53
mdzpitti: I assume you're talking about the build configuration, i.e. /boot/config-`uname -r`15:54
pittimdz: debdiff on .debs just shows the file additions/removals, not the file content diffs, after all15:54
pittimdz: yes, that15:54
mdzpitti: oh, of course. yes, naturally the contents need to be compared as well15:54
apwpitti, right we have beeing doing the binary debdiffs internally before submission, clearly you cannot see that with the current process15:54
cjwatsonyes, it would have to be a content comparison of the text files15:54
pittiapw: yes, I trust you on that; my concern is/was just that there is a lot of other changes which could happen which doesn't reflect in debdiff15:55
mdzI forgot that debdiff didn't show the changes to files in the binary packages15:55
cjwatsonok, I think we have something approaching consensus.  how about I go off and draft a chunk of policy text for this?15:55
cjwatsonno offence to anyone but I really don't want ever to have to have this conversation again ;-)15:55
apwpitti, i would not want you to think i don't hear your concerns, they are valid and it is your job as gate keeper to keep us honest15:55
mdzcjwatson: you mentioned you felt pressured in your SRU role to let this through despite it being beyond your mandate as you understood it. is that an issue we should discuss?15:56
pittiso, if we can get a build log/compiler flag/config diff check in addition, I'm happy to review the stripped down patch; it's a lot easier than the 3.2 MB monster that Launchpad threw at us15:56
cjwatsonperhaps, but maybe over beer15:56
smbActually I was for now to ask cjwatson to reject the current uploads15:56
cjwatsonwe're running out of time in this meeting15:56
mdzI want to support a strong SRU team which can push back on developers on behalf of users15:56
pittianother thing to consider is that very few developers still run karmic15:57
pitti(i. e. the folks who would come to us and tell us about regressions)15:57
pittiwrt. the "spot regressions in proposed" part15:58
cjwatsonmy last item is very quick, and then perhaps we can take the rest to e-mail given that we have rough consensus here15:58
smbpitti, Just to say that but Lucid fsl-imx51 is Karmic kernel15:58
cjwatson[TOPIC] DMB member replacement (cjwatson)15:58
MootBotNew Topic:  DMB member replacement (cjwatson)15:58
cjwatsonThe DMB has received a resignation note from Richard Johnson15:59
cjwatsonI'm ashamed to say I have no idea of the procedure for replacing him15:59
cjwatsonDo DMB members need to be nominated by sabdfl?15:59
* pitti tries to remember how we nominated the first board, aside from the existing TB/MOTU boards16:00
mdzwe bootstrapped DMB by double-booking the TB16:00
mdzand then solicited nominations from developers16:00
mdzi.e. developers were nominated by their peers, and then there was a general election16:01
pittiIMHO we should do the same: advertise the vacancy on u-d-a@ and then vote16:01
cjwatsonOK, I'll sort that out then, thanks16:02
mdzI think the DMB itself can manage the election this time16:02
cjwatsonsucks to be us ;-)16:02
cjwatson[TOPIC] AOB16:02
MootBotNew Topic:  AOB16:02
cjwatsonok, that'd be nothing then16:04
MootBotMeeting finished at 10:04.16:04
cjwatsonthanks all, I think this was productive16:04
pittithanks everyone16:04
* manjo zooms in17:58
* JFo mans the flak cannon17:58
* smb looks with one eye17:59
MootBotMeeting started at 12:00. The chair is bjf.18:00
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]18:00
bjf[LINK] https://wiki.ubuntu.com/KernelTeam/Meeting18:00
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting18:00
bjf[LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick18:00
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick18:00
bjf# NOTE: '..' indicates that you are finished with your input.18:00
bjf[TOPIC] ARM Status (lag)18:00
MootBotNew Topic:  ARM Status (lag)18:00
lag - Marvel (mvl-dove)18:00
lag    - Nothing new this week18:00
lag - Freescale (fsl-imx51)18:00
lag    - Nothing new this week18:00
lag - Texas Instruments (ti-omap)18:00
lag   - REBASE   : ti-omap4 branch is now at 901.4.18:00
lag   - PATCH    : Patches applied which raise uevents to load Syslink driver modules18:00
lag   - PATCH    : ti-omap4 patches posted for review - sebjan requested to do the same18:00
lag   - PATCH    : Several patches from TI have been reviewed and merged into our kernel18:00
lag   - ON GOING : B593650 was once again reproducible - this is next on mpoirier's hit-list18:01
lag   - ON GOING : B601226 patch has been sent upstream - awaiting feedback18:01
lag   - ON GOING : B592295 a patch and RFC has been set out by TI - awaiting feedback18:01
lag   - ON GOING : B477106 is sleeping until further notice18:01
lag   - FIXED    : B594382 was fixed in rc4 - was probing for daisy-chain event rather than daisy-chain en bit18:01
bjf[TOPIC] Release Metrics: (JFo)18:01
MootBotNew Topic:  Release Metrics: (JFo)18:01
JFoBugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs)18:01
JFoRelease Meeting Bugs (4 bugs, 9 Blueprints)18:02
JFo==== Alpha 3 Milestoned Bugs (46 across all packages (down 5)) ====18:02
JFo * 4 linux kernel bugs (no change)18:02
JFo * 0 linux-fsl-imx51 bugs18:02
JFo * 0 linux-ec2 bugs18:02
JFo * 0 linux-mvl-dove bugs18:02
JFo * 1 linux-ti-omap bugs (up 1)18:02
JFo * 1 linux-meta-ti-omap bug (no change)18:02
JFo==== Release Targeted Bugs (102 across all packages (down 5)) ====18:02
JFo * 7 linux kernel bugs (no change)18:02
JFo * 2 linux-fsl-imx51 bugs18:02
JFo * 0 linux-ec2 bugs18:02
JFo * 2 linux-mvl-dove bugs18:02
JFo * 3 linux-ti-omap bugs (up 1)18:02
JFo * 1 linux-meta-ti-omap bug (no change)18:02
JFo=== Milestoned Features ====18:02
JFo * 14 blueprints18:02
JFo*** NOTE: This listing includes HWE Blueprints***18:02
JFo==== Bugs with Patches Attached:120 (up 5) ====18:02
JFo * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on18:02
JFo * Breakdown by status:18:02
JFo   http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/18:02
bjf[TOPIC] Blueprint: kernel-maverick-apparmor (jjohansen)18:02
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor18:02
MootBotNew Topic:  Blueprint: kernel-maverick-apparmor (jjohansen)18:02
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor18:02
jjohansenBug #599450 - more complicated than originally though due to semantic issues.  atm done with kernel side, current plan is to handle rest user side.18:03
jjohansenBug #602261 - looks to be AppArmor exacerbating Bug #600359.  Have applied18:03
jjohansena kernel patch that should reduce this by adjusting AA policy memory allocations,18:03
jjohansenand have also applied some patches to user space tools reduce memory usage.18:03
jjohansenBug #581524 - Partial kernel fix in place, still triggers in one case that is currently being examined.   Userspace portion of fix is being tested.18:03
jjohansenNext submit is queued, and ready to go out pending regression tests that are running on the updated rebase.18:03
ubottuLaunchpad bug 599450 in linux (Ubuntu Maverick) "[apparmor] getattr handled incorrectly in 2.6.35-6.7" [High,New] https://launchpad.net/bugs/59945018:03
ubottuLaunchpad bug 602261 in linux (Ubuntu) "Thrashing and OOM during upgrade from 10.04 to Maverick" [High,Confirmed] https://launchpad.net/bugs/60226118:03
ubottuLaunchpad bug 600359 in ureadahead (Ubuntu Maverick) "ureadahead generating oom messages during boot." [Medium,Confirmed] https://launchpad.net/bugs/60035918:03
ubottuLaunchpad bug 581524 in Ubuntu Manual "string 392 missing, "you" and "your"" [Low,Fix committed] https://launchpad.net/bugs/58152418:03
JFothat last bug looks odd18:04
jjohansenindeed that is right18:04
bjf[TOPIC] Blueprint: kernel-maverick-misc (apw)18:04
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc18:04
MootBotNew Topic:  Blueprint: kernel-maverick-misc (apw)18:04
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc18:04
apwNothing new to report.18:05
bjf[TOPIC] Blueprint: kernel-maverick-new-kernel-on-lts (tgardner)18:05
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts18:05
MootBotNew Topic:  Blueprint: kernel-maverick-new-kernel-on-lts (tgardner)18:05
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts18:05
bjfNothing new this week.18:05
bjf[TOPIC] Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)18:05
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel18:05
MootBotNew Topic:  Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)18:05
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel18:05
jjohansenReceived confirmation from Amazon contacts that pv-ops based kernels should work in EC2, and that the xsave hypercall needs to be disabled or there will be issues with booting kernels.18:05
jjohansenHave built a test kernel but haven't tested yet.18:05
=== zyga is now known as zyga_
jjohansenJFo: it was Bug #58152518:06
ubottuLaunchpad bug 581525 in apparmor (Ubuntu) "Lucid: system becomes unstable randomly, seems related with apparmor" [Undecided,New] https://launchpad.net/bugs/58152518:06
JFoah :)18:06
bjf[TOPIC] Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)18:07
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review18:07
MootBotNew Topic:  Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)18:07
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review18:07
ogasawaraNothing new to report this week.18:07
bjf[TOPIC] Blueprint: kernel-maverick-config-review (ogasawara)18:07
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-config-review18:07
MootBotNew Topic:  Blueprint: kernel-maverick-config-review (ogasawara)18:07
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-config-review18:07
ogasawaraNothing new to report this week.18:07
bjf[TOPIC] Blueprint: kernel-maverick-bug-handling (JFo)18:07
bjf[LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling18:07
MootBotNew Topic:  Blueprint: kernel-maverick-bug-handling (JFo)18:07
MootBotLINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling18:07
JFoLocation chosen for the Triage Summit. It will be a combination of the #ubuntu-classroom and the #ubuntu-kernel channels. The classroom will be for the instructional sessions and the kernel channel will be used for wiki development and further discussion. Let me know your thoughts on this. We'll be discussing classes, scheduling and topics at the Rally next week.18:07
bjf[TOPIC] Blueprint: kernel-maverick-upstart (apw)18:08
bjf[LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart18:08
MootBotNew Topic:  Blueprint: kernel-maverick-upstart (apw)18:08
MootBotLINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart18:08
apwNothing new to report.18:08
bjf[TOPIC] Blueprint: kernel-maverick-bios-test-automation (cking)18:08
bjf[LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bios-test-automation18:08
MootBotNew Topic:  Blueprint: kernel-maverick-bios-test-automation (cking)18:08
MootBotLINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bios-test-automation18:08
bjfno cking i guess18:09
bjf[TOPIC] Status: Maverick (ogasawara)18:09
MootBotNew Topic:  Status: Maverick (ogasawara)18:09
ogasawaraThe Maverick kernel was rebased to the latest 2.6.35-rc4 mainline kernel last week and is currently availble for testing in the latest 2.6.35-7.12 upload.  2.6.35-rc5 was released yesterday.  We'll rebase our Maverick tree today and upload for testing.18:09
ogasawaraAlpha 3 is Thurs Aug 5th which is ~3weeks away.  We are above the Alpha 3 burn down chart's trend line, so please review the list of work items for Alpha 3 and start closing out tasks.  Remember you won't have as much time to tackle work items next week due to the sprint.18:09
ogasawara[LINK] http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-3.html18:09
ogasawara[LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone maverick-alpha-318:09
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-3.html18:09
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone maverick-alpha-318:09
bjf[TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)18:11
MootBotNew Topic:  Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)18:11
smbDapper:      2.6.15-55.84  (security)18:11
smbHardy:       2.6.24-28.71  (updates)18:11
smbJaunty:      2.6.28-19.61  (security)18:11
smbKarmic:      2.6.31-22.60  (security)18:11
smb             2.6.31-22.61  (waiting for approval)18:11
smb - mvl-dove  2.6.31-214.28 (security)18:11
smb             2.6.31-214.29 (waiting for approval)18:11
smb - fsl-imx51 2.6.31-112.28 (security)18:11
smb             2.6.31-112.29 (waiting for approval)18:11
smb - ec2       2.6.31-307.15 (security)18:11
smb             2.6.31-307.16 (waiting for approval)18:11
smbLucid:       2.6.32-23.37  (updates)18:11
smb             2.6.32-24.38  (proposed)[ 8]  1/ 4 verifications done (+ 1)18:11
smb - LBM       2.6.32-24.17  (proposed)[ 7]  0/ 1 verifications done18:11
smb - mvl-dove  2.6.32-206.19 (updates)18:11
smb             2.6.32-207.20 (proposed)[ 5]  1/ 4 verifications done (+ 1)18:11
smb - fsl-imx51 2.6.31-608.15 (updates)18:11
smb - ti-omap   2.6.33-502.8  (updates)18:11
smb - qcm-msm   2.6.31-802.5  (updates)18:11
smb - ec2       2.6.32-307.12 (updates)18:11
smb             2.6.32-308.13 (proposed)[ 5]  1/ 4 verifications done (+ 1)18:11
smbSecurity update is prepared and pending, waiting for Lucid proposed moving to18:11
smbErr, actually18:12
smbKarmic uploads have been rejected on my request for now18:12
smbWe try to restore normality if we know what that is anyway.18:12
* apw laughs :)18:12
bjf[TOPIC] Incoming Bugs: Regressions (JFo)18:12
MootBotNew Topic:  Incoming Bugs: Regressions (JFo)18:12
JFoIncoming Bugs18:12
JFo59 Maverick Bugs (up 9)18:12
JFo1049 Lucid Bugs (up 21)18:12
JFoCurrent regression stats (broken down by release):18:12
JFo==== regression-potential ====18:12
JFo  * 35 maverick bugs (up 8)18:12
JFo  * 223 lucid bugs (down 1: to be converted to regression-release)18:12
JFo==== regression-update ====18:12
JFo  * 40 lucid bugs (no change)18:12
JFo  * 6 karmic bugs (no change)18:12
JFo  * 4 jaunty bugs (no change)18:12
JFo  * 1 hardy bug (no change)18:12
JFo==== regression-release ====18:12
JFo  * 160 lucid bugs (up 9)18:12
JFo  * 45 karmic bugs (no change)18:12
JFo  * 19 jaunty bugs (no change)18:12
JFo  * 2 hardy bugs (no change)18:13
JFo==== regression-proposed ====18:13
JFo  * 2 lucid bugs (up 1)18:13
JFo  * 1 karmic bug (no change)18:13
JFoI've been slack in moving Lucid bugs from r-p to r-r18:13
JFobut will get back on that week after next18:13
bjf[TOPIC] Incoming Bugs: Bug day report (JFo)18:13
MootBotNew Topic:  Incoming Bugs: Bug day report (JFo)18:13
JFoThe Community bug Day next week has been canceled due to the Platform Rally. It will resume the week after the Rally. I'll be sending an e-mail update next week concerning the items that we will be focusing on. Also, it was determined that there is a need to hold our Kernel Tema Bug Day earlier in this week due to the travel time needed to arrive at the Platform Rally. We will be holding the Team Bug Day tomorrow, Wednesday 14 July. The expectatio18:13
JFon is that all platform kernel engineers will look at a minimum of 5 bugs each. The day will start at 8AM PST and run for about 3 hours. This is so that we can chat about the bugs being worked so as to avoid duplicating any efforts.18:13
JFothere is a calendar item for the bug day tomorrow.18:13
bjf[TOPIC] Open Discussion or Questions: Anyone have anything?18:14
MootBotNew Topic:  Open Discussion or Questions: Anyone have anything?18:14
bjfPlease note that there will not be a Kernel team meeting next week.18:15
bjfJFo, go18:15
JFoThere is a kernel triage chat tomorrow afternoon at 4PM EST18:15
JFoany Kernel Engineers interested in backing me up are welcome to attend :)18:15
ogasawarahttps://wiki.ubuntu.com/UbuntuDeveloperWeek -> more info there18:15
JFothanks ogasawara18:16
bjfkamal, go18:16
kamalbug 594837 (my usual topic)18:16
ubottuLaunchpad bug 594837 in linux (Ubuntu) "Lucid SRU: Intel Core i3/i5/i7 hang on resume from suspend (SCI_EN)" [High,In progress] https://launchpad.net/bugs/59483718:16
kamalThis is still pending review at stable@kernel.org (4 weeks).   I think this affects a good number of users who would like it fixed in Lucid sooner rather than later.  I think its a safe fix (its in Maverick).18:16
kamalIs it time for us to SRU this for Lucid or shall we continue to wait for stable?18:16
apwwell lucid is now undergoing a security update, so it'll be a while before we can put anything new in there18:16
smbkamal, Right18:17
kamalmay as well let it wait another week then :-)18:17
smbkamal, Don't expect things to change next week18:17
smbkamal, There is a sprint going on... :)18:17
kamalok, another *two* weeks then!  ;-)18:17
bjfthanks everyone18:17
MootBotMeeting finished at 12:17.18:17
JFothanks bjf18:17
manjothanks bjf18:17
kamalthanks bjf18:17
JFowe are an efficient machine :)18:18
kamalyeah, fastest kernel team meeting ever18:18
* smoser is scribe19:01
jiboumanssmoser is chair!19:01
smoserok. so i guess we go.19:02
MootBotMeeting started at 13:02. The chair is smoser.19:02
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]19:02
* ttx bows to the Big Smoser19:03
=== Ursinha is now known as Ursinha-afk
smoser#topic Review ACTION points from previous meeting19:03
ttx[TOPIC] ...19:03
smoser[TOPIC] Review ACTION points from previous meeting19:03
MootBotNew Topic:  Review ACTION points from previous meeting19:03
smosersommer waiting on mdke re: refresh issue19:03
smoser(that is our only action point)19:04
smosersommer, ?19:04
smoserhm... sommer was here 5 minutes ago.19:04
sommerI think it was fixed19:04
sommeryep it's updated19:05
ttxsommer: thanks !19:05
smoser[TOPIC] Maverick development (jib)19:05
MootBotNew Topic:  Maverick development (jib)19:05
jiboumansI sent out the Alpha3 update to the mailinglist the other day19:05
jiboumanswe're mostly on track for the high priority blueprints: http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-3.html19:05
jiboumansbut we're very heavily loaded this cycle19:05
jiboumansLow prio blueprints are at risk of being postponed19:06
jiboumansnone-feature stuff can be moved to the Betas, but feature development may have to wait until Maverick+1 for those19:06
jiboumansApport hooks are a special case here and we have an agenda item for that further down19:06
jiboumansttx, can you take us through the specific blueprints here?19:06
ttxthe specific blueprints that may have to wait, or those that are Low and might need to be postponed ?19:07
jiboumanssorry, i meant the next item on the agenda19:07
jiboumansthe subcycle tracking :)19:07
* jiboumans notices his segway was no where nearly as smooth as imagined19:07
smoser[TOPIC] Alpha3 subcycle status (ttx)19:08
MootBotNew Topic:  Alpha3 subcycle status (ttx)19:08
ttxI don't have so much to add to your brilliant analysis19:08
SpamapSjiboumans: more hand waving19:08
ttxI'd like to have more work items burnt19:08
ttxsince it looks like we didn't do any work, while I know it's not the case19:08
* SpamapS has got a fever, and the only prescription, is more hand waving19:08
jiboumansseconding what ttx said; several people under 10% completion now is a red flag19:09
SpamapSttx: I'm spinning on a few in parallel due to external factors (mostly debian sponsorship/bugs/etc), I'd expect 3 or 4 to go DONE all at once.19:09
ttxi'll have discussions with spec assignees soon to confirm expectations19:09
ttxSpamapS: ack, next time try to decorrelate work and sponsoring wait to avoid that19:10
ccheneymy uec provisioning work is very interrelated and i think i can probably get them all done quickly once i get one blocker resolved19:10
ttxpackage FOO / package BAR / get sponsoring for FOO and BAR19:10
ttxthat allows to keep the ball smoothly rolling19:10
jiboumansccheney: what's your blocking factor?19:10
SpamapSttx: we can discuss later to make sure I've done that properly (I think I may have.. and its just that they're all in the "get sponsoring for FOO and BAR" state now)19:11
ttxSpamapS: ah! that happens :)19:11
ccheneyjiboumans, powerwake seems to need to write to the home directory but when running from apache2 has none, so it blows up19:11
ccheneyjiboumans, i'm not sure how this worked in the past but it doesn't work for me while trying to set it up due to that19:11
ccheneyi thought it was an issue with the machines i was using not waking up properly, which seemed to happen occasionally but the main issue was the home dir problem19:12
jiboumansccheney: i assume worst case you can workaround manually and continue testing?19:12
ccheneyjiboumans, well to get it working in a packaged and tested manner i need to get that part resolved asap19:13
ccheneyi emailed kirkland but it appears he may be off atm?19:13
SpamapSttx: as a side issue, I need to chat w/ Mathias a bit about some things that aare 90% done in the monitoring spec, so those should roll to DONE or even come off the list altogether after I talk to him.19:13
hallynyeah he's at a conf19:13
jiboumansccheney: he's at a conference19:13
ccheneyjiboumans, oh ok19:13
ttxSpamapS: ok, you seem to be on top of it19:14
ccheneyis there a better version of uec.py somewhere other than kirkland's bzr repo? i wasn't sure if it was the main branch19:14
ttxsmoser: that's all from me19:14
smoser[TOPIC] Weekly Updates & Questions for the QA Team (hggdh)19:15
MootBotNew Topic:  Weekly Updates & Questions for the QA Team (hggdh)19:15
ttxccheney: I think kirkland has the most recent one19:15
ttxccheney: it's a merge from several code bases, including mine19:15
SpamapShggdh: Just a comment, I had no idea about the UEC rig, thanks for emailing that info!19:15
jiboumanshggdh: i see the blueprint for server-maverick-qa-workflow is progressing nicely19:16
hggdhjiboumans: yes... I had to stop for a while on the UEC testing to cater for the other tasks/blueprints19:16
jiboumanshggdh: is it worth a section in one of the coming meetings to introduce people to it (or some blog posts?)19:16
hggdhjiboumans: about the internal UEC rig ?19:17
jiboumanshggdh: server-maverick-qa-workflow19:17
hggdhah. Sorry. Yes, it would be a good idea19:17
jiboumanshggdh: i trust you'll add it to the agenda when appropriate?19:18
hggdhjiboumans: albeit trusting me has been proved to be dangerous, yes, I will add it in19:18
jiboumanshggdh: already editing the blueprint with a WI ;)19:18
smoser[ACTION] hggdh to discuss server-maverick-qa-workflow at future meeting19:19
MootBotACTION received:  hggdh to discuss server-maverick-qa-workflow at future meeting19:19
jiboumanshggdh: at my age, i can hardly trust my brain to remember things19:19
smosermoving on ?19:19
* hggdh wonders about self's age...19:19
hggdhI am done, smoser19:19
smoser[TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)19:19
MootBotNew Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)19:19
jjohansensorry, can't seem to find my notes now19:20
smoser[TOPIC] Bug 597387: Maverick EC2 kernel issue19:21
MootBotNew Topic:  Bug 597387: Maverick EC2 kernel issue19:21
ubottuLaunchpad bug 597387 in Ubuntu Maverick "pv-ops kernel only works in 3 or 4 zones in EC2" [High,Confirmed] https://launchpad.net/bugs/59738719:21
jiboumanssmoser: did you give me an update on that one yesterday? or was that unrelated?19:21
jjohansenso we received confirmation from Amazon contacts that pv-ops kernels work on EC2 and that they need xsave hypercall disabled19:21
smoseri dont think it was related. i dont recall anything yesterday.19:22
smoserjjohansen is on top of it.19:22
jjohansenI have built a pv-ops kernel but haven't tested it yet19:22
smoserso new kernel built and awating test in different regions ?19:22
jjohansenawaits any boot testing19:22
jjohansenI just haven't gotten that far yet19:23
jjohansenbut that should happen this afternoon19:23
jjohansenBug #57606619:23
smoser[TOPIC] Bug 576066: ums-cypress.ko missing from server installer19:23
MootBotNew Topic:  Bug 576066: ums-cypress.ko missing from server installer19:23
ubottuLaunchpad bug 576066 in linux (Ubuntu Lucid) "ums_cypress missing from lucid server cd" [Low,In progress] https://launchpad.net/bugs/57606619:23
jjohansenTim has prioritized, and is taking care of this19:23
smoser[TOPIC] atop kernel patch19:24
MootBotNew Topic:  atop kernel patch19:24
jiboumansjjohansen: i only saw a handful of replies on the mailing-list19:24
jjohansenthere hasn't been any more input on this yet19:24
jjohansenas it stands I don't see the kernel team picking up the patches19:25
jiboumansjjohansen: the use case highlighted of seeing what process is using bandwidth and the historical resource consumption are the two use cases i know19:25
* ttx struggles a bit with his connection19:25
jiboumansif there are alternate tools, that would be good to know of. i dont know any though19:25
jiboumansjjohansen: do you know of any that could provide that functionality instead?19:26
jjohansenjiboumans: I am not aware of any either19:26
SpamapSHonestly, since discovering atop when I first heard about this, I've used it twice for my own issues, and a friend who I told about it used it to solve a pretty serious IO problem on his production servers.19:26
jiboumansjjohansen: ok, i'll chime in on the thread19:26
SpamapSatop is t3h awesome19:26
jiboumansit is19:26
jjohansenhtop is better than top but I don't think it does19:26
jjohansenSpamapS, jiboumans: please chime in19:26
SpamapSnothing I've ever seen can tell me which process is doing which IO operations19:27
jiboumansdoing so now19:27
ttxthere is a EC2 performance issue filed against "Ubuntu on EC2", I'm trying (unsuccessfully) to get to its bug number19:27
smoser[ACTION] jiboumans to chime in on atop thread19:27
MootBotACTION received:  jiboumans to chime in on atop thread19:27
smoserbug 574910: I've been pinged again on this, per erichammond, it is preventing pe19:27
smoserople from moving to lucid as perceived performance drop.  It would be really nic19:27
smosere to address it.  even if we can't fix it, to clearly state that performance is19:27
smoserthe same as it was or better (maybe some benchmarks?)19:27
ubottuLaunchpad bug 574910 in linux-ec2 (Ubuntu) "High load averages on Lucid while idling" [Undecided,In progress] https://launchpad.net/bugs/57491019:27
jjohansenjiboumans: also if this is really import let pete/tim know19:27
smoser(that is ttx's bug probably)19:27
ttxsmoser: yes, thanks19:27
SpamapSWe should also contact the KSLM author about this, which is probably "the right way" for atop to function19:27
=== dharman_ is now known as dharman
jjohansensmoser: right, in my limited testing it looked like accounting but we need to do some more testing19:28
jjohansenSpamapS: KSLM?19:28
SpamapSwww.headinthecloud.net  and  http://launchpad.net/kslm19:28
SpamapSCole Crawford19:28
jjohansenah, thanks19:29
SpamapSI spoke with him at UDS about some unrelated monitoring stuff..19:29
SpamapSbut I think kslm is an attempt to do what atop does, but in a less invasive way19:29
jjohansenokay, we need to look into it then19:30
jiboumansSpamapS: chime in on the thread? :)19:30
smoserok. so, we really need to address the bug 574910 one way or another.  I hesitate to ask here for how, as I believe its going to result in work for me.19:31
ubottuLaunchpad bug 574910 in linux-ec2 (Ubuntu) "High load averages on Lucid while idling" [Undecided,In progress] https://launchpad.net/bugs/57491019:31
jiboumansaction smoser to just fix it? ;)19:31
jjohansensmoser: I will make some time to look at it again tomorrow19:32
smoserwe really, really, really dont want people using our images to stay on karmic or hardy.19:32
jjohansenthe kt is doing a bug day, and its on my list19:32
smoserjjohansen, ok. thank you. please get something there.  i realize its probably just a bad metric, but it appears at least to be a popular bad metric.19:32
SpamapSjiboumans: chiming. :)19:32
smoseranyone have anything else for jjohansen ?19:32
jiboumansjjohansen: smells of io19:33
jiboumansjjohansen++ # kernel hackery19:33
* jjohansen needs a shower19:33
smoser[TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)19:33
MootBotNew Topic:  Weekly Updates & Questions for the Documentation Team (sommer)19:33
sommerdon't have anything new this week, but should have some updates for next week19:33
sommeranyone else have questions comments for me?19:34
jiboumanssommer: maybe out of your scope, but i get questions about cloud-init / cloud-config regularly19:35
jiboumansare we covering this in our docs as well?19:35
* smoser ducks19:35
sommerjiboumans: not too sure, but I can definitely check on that for next week19:35
jiboumansit's mostly 'how do i..' and then 'oh that is so easy with cloud-*'19:35
smoser[ACTION] sommer to check on getting some cloud-init / cloud-config doc19:35
MootBotACTION received:  sommer to check on getting some cloud-init / cloud-config doc19:35
jiboumanssommer: that'd be great. they're amazing tools but not everyone's discoverd them yet19:36
sommercool, I'll focus on updating that section19:36
jiboumanssommer++ thanks19:36
smoser[TOPIC] Weekly SRU review (zul)19:36
MootBotNew Topic:  Weekly SRU review (zul)19:36
jiboumansttx, can you take that?19:36
jiboumanszul's at a conference today and i dont think he managed to join in19:36
=== Andre_Gondim is now known as Andre_Gondim-afk
zulactually im here briefly19:38
jiboumanszul: then, if you don't mind19:38
zulwe have recieved 2 requests this week19:38
zulthe list went out on monday both are virt related i dnot have the bug numbers in front of me though19:39
zulso they will be looked at on friday and be added to the list for next week19:39
hallynbug #57958419:39
ubottuLaunchpad bug 579584 in libvirt (Ubuntu) "setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu" [Medium,Fix released] https://launchpad.net/bugs/57958419:39
zulthats one of them ;)19:40
smoseri nominated bug 598649 .19:40
ubottuLaunchpad bug 598649 in qemu-kvm (Ubuntu) "cannot boot grub multiboot image with kvm -kernel" [Medium,Fix released] https://launchpad.net/bugs/59864919:40
smoserit will require some hallyn work, but a working backport would allow us to run maverick guests with instance-servicable kernels in lucid hosts.19:40
hallynsmoser: hm, the problem with that one is we'd have to do pretty big updates for kvm+seabios for lucid19:40
smoserhallyn, yeah. i expected that as a possibility.19:41
hallyni.e. we'd have to update to qemu 12.419:41
jiboumansthe other is bug #60336319:41
ubottuLaunchpad bug 603363 in openssh (Ubuntu) "sshd never stops, prevents umount of /usr partition" [Medium,Fix released] https://launchpad.net/bugs/60336319:41
zulunfortunately the wireless here is sucking19:41
zulso thats it for me19:42
smoser[TOPIC] Rubygems in Ubuntu (SpamapS)19:42
MootBotNew Topic:  Rubygems in Ubuntu (SpamapS)19:42
SpamapSIts unfortunate that Mathiaz isn't here so he can comment on the past, but I'll share the current19:43
SpamapSeverybody who uses ruby, uses rubygems.. and it is horribly broken for most people in Debian and ubuntu19:43
SpamapSthe main gripe is that it stores binaries that would normally be placed in /usr/bin or (by configuration) /usr/local/bin, in /var/lib/rubygems19:44
SpamapSSo at Velocity and DevOps days, after discussing with quite a few ruby developers who love ubuntu but hate ubuntu's rubygems, we need to come up with a strategy to make sure ruby developers can use rubygems the way they expect to.19:44
SpamapSmathiaz tried to "fix" this 2 years ago but had his upload reverted.19:45
smoserso do we want to add this to next weeks agenda with Mathiaz here and leave this as a teaser ?19:46
SpamapSAny thoughts on this issue? I feel strongly that it should place files in /usr/local/bin but the debian developer disagrees and says that FHS requires it go in /var/lib19:46
zuli dont think anything should be placed in /usr/local/bin19:46
zulsorry laggy19:46
SpamapSI'd like to make sure we all come to the sprint educated on the issue so we can leave Prague with an action plan.19:46
SpamapSzul: we allow CPAN to do that.19:47
SpamapSand every autoconf script out there puts things in /usr/local19:47
smoserSpamapS, by default cpan on ubuntu/debian puts things in /usr/local ?19:47
SpamapSsmoser: as I type this, I'm not 100% sure that it does. I think my memory is based entirely on redhat's CPAN. :-/19:48
SpamapSwhich does /usr/bin19:48
SpamapSBut it remains an important issue19:49
smoserusr/bin just seems dirty.19:49
jiboumanscpan on debian didn't used to be well behaved19:49
jiboumanslet me check19:49
SpamapSusers want these executables in their path19:49
* ttx is kinda back19:49
ttxat ~40% packet loss19:49
jiboumansyeah, i think cpan is still naughty19:49
SpamapSit breaks things mightily for the executables to be in /var/lib (which some might argue, can be mounted noexec)19:49
smoserso what do we want to do here ?19:50
jiboumans$ perl -MConfig -le'print $Config{installbin}'19:50
jiboumans /usr/bin19:50
SpamapSjiboumans: doh19:50
SpamapSsmoser: we want to make sure users can use the software the way they want to.19:51
jiboumansspamaps: this is what local::lib and INSTALLDIRS=site is for, but it's not the default19:51
SpamapSsmoser: without encouraging stupidity. ;)19:51
SpamapSright now, *everybody* reinstalls rubygems from source19:51
smoserwell, i meant regarding this discussion.19:51
SpamapSthe options we came up with were:19:51
SpamapSa) switch to using the embedded rubygems from ruby 1.919:52
ttxSpamapS: if you haven't had this discussion with mathiaz, you should19:52
ttxSpamapS: he got burnt in those waters already19:52
SpamapSb) attempt to re-do the change mathiaz did, after discussion with motu council19:52
SpamapSc) attempt to wrest control of the debian package away from people by calling attention to  the fact that nobody likes the way it works now.19:53
SpamapSttx: mathiaz and I discussed it at length with several ruby users and authors including the Chef guys.19:53
ttxSpamapS: ok, I was missing some context, I see19:53
SpamapSttx: Jos also had some other discussions on the same vein.19:54
zul`maybe send an email to -devel and -serve to get more feedback19:54
SpamapSEither way, it was by far the most common complaint I got about Ubuntu Server at velocity.19:54
jiboumansit's a recurring theme for me19:54
jiboumansi'm open to any route forward, just not one that leaves an essential package in a state that the its users can't actually use19:55
ttxSpamapS: it's good for me to see it's no longer about how much our Tomcat sucks19:55
SpamapSttx: :-D19:55
jiboumansttx++ # fixing tomcat ;)19:55
smosermdz blogged on related topic recently: http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/19:55
smoser(not to just name drop, but i think it is generally larger than just ruby, and growing.19:56
smoserare we ready to move on ?19:56
smoserwe're back to zul19:56
smoser[TOPIC] Apport hooks call for participation (zulcss)19:56
MootBotNew Topic:  Apport hooks call for participation (zulcss)19:56
jiboumanshang on19:56
SpamapSLets find the biggest ruby community(ies) and ask for their guidance. Maybe a huge community outpouring of need will be enough to enact change.19:56
jiboumanswhat action are we taking SpamapS?19:56
SpamapSshould I contact jcastro?19:57
jiboumansspamaps: adam and james will also be able to point you at relevant communities19:57
jiboumansand yes, contact jcastro19:57
jiboumansspamaps: is there anything that would be required to be resolved before feature freeze for it to make maverick?19:57
jiboumansor is maverick too optimistic?19:58
SpamapSjiboumans: not sure.19:58
SpamapSif you ask me, the package is 100% broken and this is SRU worthy given users complete abandonment of the package.19:58
jiboumansSpamapS: think about the options in that context too.. i'd love to see something workable already in maverick19:59
smoserwell, nothing is SRU worthy unless fixed in development release.19:59
jiboumansSpamapS: can you get the discussion rolling and update us next week in prague?20:00
jiboumanswe'll then revisit here in the next irc meeting20:00
SpamapSYes I will email -devel and try to get the ruby community's position before next Tuesday.20:00
smoser[ACTION] SpamapS to send mail to -devel to get ruby community position on ruby gems in ubuntu20:01
jiboumanssmoser, action spamaps please?20:01
MootBotACTION received:  SpamapS to send mail to -devel to get ruby community position on ruby gems in ubuntu20:01
jiboumansthanks :)20:01
smosernow moving on ?20:01
=== zyga is now known as zyga_
jiboumansyes please20:01
smoser[TOPIC] Apport hooks call for participation (zulcss)20:01
MootBotNew Topic:  Apport hooks call for participation (zulcss)20:01
jiboumansi'll take that one20:02
jiboumanszul's connection is flaky20:02
jiboumansso, as i mentioned above, our commitment for Alpha3 is quite high20:02
jiboumansand that means we're not likely to get many new apport hooks this cycle20:02
jiboumansand that'd be a real shame.20:03
jiboumansas this project is shaped very much like papercuts are, Zul wanted to issue a call for participation, both for apport hooks suggestions, but more importantly also for contributions20:03
jiboumansI highlighted this in the Alpha3 update here: https://lists.ubuntu.com/archives/ubuntu-server/2010-July/004411.html20:03
jiboumansand zul will be sending out something specific to apport hooks in the next day or two20:04
jiboumansif you have some spare cycles and have a package you care about with apport hooks, please consider contributing one!20:04
jiboumansI hope i represented zul's thoughts well there20:04
jiboumanssmoser: that's it from me20:04
smoser[TOPIC] Open Discussion20:04
MootBotNew Topic:  Open Discussion20:05
smoseri have one, just a re-announcement:20:05
smoserec2 cluster compute : http://aws.typepad.com/aws/2010/07/the-new-amazon-ec2-instance-type-the-cluster-compute-instance.html .  for $1408/hour you can have a top 500 supercomputer.  Interesting things to note here is that cluster-compute nodes have to be HVM.  Right now, there are no ubuntu HVM nodes, and its very unclear how you would even create one other than running 'ec2-create-snapshot' from inside one.20:05
ttxsmoser: what's HVM ?20:06
smoser(note, the $1408/hour is 880 * $1.6, which places 146 on Top 500)20:07
ttxThanks everyone for assigning yourself to papercuts... don't forget to fix them before the end of the subcycle !20:07
smoserHVM is hardware assisted virtualization.  basically kvm but on xen.20:07
smoserits using the same infrastructure that windows instances previously used. (at least it seems to be)20:07
smoserok. nothing else, then20:08
smoser[TOPIC] Announce next meeting date and time20:08
MootBotNew Topic:  Announce next meeting date and time20:08
SpamapSsmoser: so is it something that is already on our radar to support, or did this come out of left field?20:08
smoserwell, most everything comes out of left field for ec2.20:08
smoserour relationship is improving, and i hope that results in better previews of this sort of thing.20:09
smoserthe hvm is something htat i always expected they'd do.20:09
smoserbut it is currently only available on the cluster compute isntance types.20:10
smoserThe meeting next week will be20:10
smoserTuesday 2010-07-20 at 1800 UTC - #ubuntu-meeting20:10
jiboumansteam, please join me on a phone call20:10
jiboumansthanks all!20:10
ttxjiboumans: that would be 8pm for most of us, next week20:10
smoserwas going to mention that.20:11
jiboumansah, good catch20:11
jiboumansusually we skip the irc meeting during a sprint week20:11
jiboumansand i think it's advisable to do so this sprint too20:11
smoserunless someone objects, then we'll resume our regularly scheduled program on20:11
=== MTeck is now known as MTecknology
smoserTuesday 2010-07-27 at 1800 UTC - #ubuntu-meeting20:11
jiboumanssmoser++ # thanks for chairing20:11
smoserthank you, and good night.20:12
MootBotMeeting finished at 14:13.20:13
=== Andre_Gondim-afk is now known as Andre_Gondim
=== MichealH__ is now known as MichealH
=== zyga__ is now known as zyga
=== MichealH is now known as i
=== i is now known as Iamnotmhall199
=== Iamnotmhall199 is now known as MichealH
=== Andre_Gondim is now known as Andre_Gondim-afk
=== Ursinha-afk is now known as Ursinha
MootBotMeeting started at 16:57. The chair is czajkowski.22:57
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]22:57
MootBotMeeting finished at 16:57.22:57
jpdsThat was quick.22:57
czajkowskisorrya bout that was the only way I could remember to get the link to the meeting log :)22:57
=== Ursinha is now known as Ursinha-afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!