| === yofel_ is now known as yofel | ||
| lollllllllllllll | bankers | 03:22 |
|---|---|---|
| === 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 | ||
| davidm | G'day NCommander | 14:00 |
| NCommander | #startmeeting | 14:01 |
| MootBot | Meeting started at 08:01. The chair is NCommander. | 14:01 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 14:01 |
| ogra | gih | 14:01 |
| ogra | *sigh even | 14:01 |
| ogra | seems we have no logs from last meeting | 14:01 |
| NCommander | ogra: ? | 14:02 |
| ogra | and dyfet_away didnt add the action items | 14:02 |
| NCommander | ugh | 14:02 |
| rsalveti | yeah | 14:02 |
| * NCommander sighs | 14:02 | |
| ogra | we had some i'm sure | 14:02 |
| ogra | i created https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100713 but indeed its empty | 14:02 |
| NCommander | I got the raw log | 14:03 |
| NCommander | [topic] Action Item Review | 14:04 |
| MootBot | New Topic: Action Item Review | 14:04 |
| ogra | ACTION 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 FTBFS | 14:04 |
| MootBot | New Topic: dyfet to work on openjdk FTBFS | 14:04 |
| ogra | thats it | 14:04 |
| ogra | going through my local logs | 14:04 |
| NCommander | ogra: I got them :-) | 14:04 |
| ogra | ah, cool | 14:04 |
| NCommander | ugh | 14:04 |
| NCommander | no dyfet_away | 14:05 |
| * NCommander sighs | 14:05 | |
| NCommander | md5sums and manifests for daily images | 14:05 |
| NCommander | c/o. probably won't get this until the sprint | 14:05 |
| ogra | manifests are stored next to the ext3 fs | 14:05 |
| ogra | so that should be trivial | 14:05 |
| ogra | md5sums will be harder :) | 14:05 |
| NCommander | ogra: it is, I just need a little time to do it:-) | 14:05 |
| ogra | yeah | 14:05 |
| ogra | no hurry | 14:06 |
| ogra | the bug is A3 targeted | 14:06 |
| ogra | worst case do it at the sprint :) | 14:06 |
| NCommander | [topic] Current Items | 14:06 |
| MootBot | New Topic: Current Items | 14:06 |
| NCommander | [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html | 14:06 |
| MootBot | LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html | 14:06 |
| NCommander | [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html | 14:07 |
| MootBot | LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html | 14:07 |
| ogra | one done | 14:07 |
| NCommander | my spec still isn't showing up | 14:07 |
| ogra | even though i was inclined to set it back to TODO | 14:07 |
| rsalveti | he moved the fuseext2 doc to TODO again | 14:08 |
| ogra | i did | 14:08 |
| NCommander | fuseext2 is marked as unstable, why are we using it? | 14:08 |
| rsalveti | oh :-) | 14:08 |
| ogra | and the other one isnt DONE either | 14:08 |
| ogra | i would at least expect the bug number mentioned somewhere and asked for that | 14:08 |
| rsalveti | NCommander: for ro only I believe it works well, the problem is rw | 14:08 |
| ogra | (the DNOE item is about filing an upstream bug) | 14:09 |
| rsalveti | but dyfet_away still needs to test it better to find the best options | 14:09 |
| ogra | yes | 14:09 |
| ogra | and need to document better | 14:09 |
| rsalveti | sure | 14:09 |
| ogra | i added some comments and talked to him this morning | 14:09 |
| ogra | anyway, all other specs are full TODO | 14:09 |
| ogra | nothing DONE yet | 14:09 |
| NCommander | ogra: how can we get improved subarch on this list? | 14:10 |
| ogra | i pinged ted about the lightweight panel but he said he has no usable code yet | 14:10 |
| ogra | NCommander, is it properly milestoned now ? | 14:10 |
| ogra | then it should show up automatically | 14:10 |
| NCommander | ogra: I thought it got fixed | 14:10 |
| NCommander | I'll lookat it again | 14:10 |
| ogra | Milestone target: | 14:10 |
| ogra | None | 14:10 |
| NCommander | [topic] Kernel Status (cooloney, mpoirier) | 14:10 |
| MootBot | New Topic: Kernel Status (cooloney, mpoirier) | 14:10 |
| ogra | still not milestoned | 14:10 |
| ogra | [topic] Kernel Status (cooloney, mpoirier, lag) | 14:11 |
| ogra | :P | 14:11 |
| mpoirier | finally done with https://bugs.launchpad.net/bugs/594382 | 14:11 |
| ubottu | Launchpad 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 wikipage | 14:11 | |
| ogra | mpoirier, sweet | 14:11 |
| mpoirier | this is now fix and done with. | 14:11 |
| mpoirier | https://bugs.launchpad.net/bugs/563650 | 14:11 |
| ubottu | Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) "DSS2 oops when shutting down while DPMS is active" [Medium,Confirmed] | 14:11 |
| mpoirier | dss2 oops when rebooting | 14:11 |
| mpoirier | seem harder to reproduce. | 14:12 |
| mpoirier | this is next on the list. | 14:12 |
| mpoirier | SDHC card is still very present. | 14:12 |
| lag | I'm assuming you don't want updating on every bug? | 14:12 |
| ogra | mpoirier, just wait until the monitor turns off and issue a shutdown or reboot via ssh | 14:12 |
| ogra | lag, no, just an overall status is fine | 14:12 |
| ogra | and bugs that you really care about to let us know | 14:12 |
| mpoirier | ogra: let's touch base after. | 14:12 |
| mpoirier | mpoirier: done with status. | 14:13 |
| lag | mpoirier: When you've finished type ".." | 14:13 |
| NCommander | [topic] QA Status (GrueMaster) | 14:13 |
| MootBot | New Topic: QA Status (GrueMaster) | 14:13 |
| GrueMaster | Not much to report. Image builds are currently broken. Last image was 7/7. | 14:14 |
| ogra | not true | 14:14 |
| ogra | i really should add you to the build reporting :P | 14:14 |
| ogra | last image is last nights build | 14:14 |
| ogra | http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100713/ | 14:15 |
| MootBot | LINK received: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100713/ | 14:15 |
| GrueMaster | last "tested" image was 7/7. Since my day hasn't officially started yet... | 14:15 |
| ogra | yeah | 14:16 |
| NCommander | can I go on? | 14:16 |
| ogra | any special bugs you want to point out ? | 14:17 |
| GrueMaster | at 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 |
| ogra | GrueMaster, if you cant use apport, just file them otherwise | 14:17 |
| ogra | (unless they are kernel bugs, i know they are a bit more strict) | 14:17 |
| ogra | i really dont care how image related bugs are filed :) | 14:18 |
| NCommander | [action] NCommander to unbreak apport retracer | 14:18 |
| MootBot | ACTION received: NCommander to unbreak apport retracer | 14:18 |
| ogra | is it broken ? | 14:18 |
| * ogra doesnt even notice | 14:18 | |
| GrueMaster | I have a workaround for the parport_pc driver oops, and have documented it in the bug I filed against it. | 14:18 |
| ogra | i think lag works on that one on the kernel side too | 14:18 |
| lag | I do | 14:18 |
| lag | I have sent a patch upstream | 14:18 |
| lag | GrueMaster: I didn't get a message? | 14:19 |
| GrueMaster | bug 603062 | 14:19 |
| ubottu | Launchpad 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/603062 | 14:19 |
| ubottu | Launchpad bug 601226 in linux-ti-omap4 (Ubuntu Maverick) "Unable to handle kernel NULL pointer dereference in ppdev module" [Medium,Triaged] https://launchpad.net/bugs/601226 | 14:19 |
| lag | Oh, the blacklist thing? | 14:20 |
| lag | Yes, okay | 14:20 |
| GrueMaster | Actually, bug 601226 | 14:20 |
| lag | The true fix should be out soon enough | 14:20 |
| * lag crosses his fingers | 14:20 | |
| * GrueMaster needs coffee still. | 14:20 | |
| lag | ;) | 14:20 |
| GrueMaster | Other than that, I have tested the fix for the daisy chain issue. Seems to have gone away. | 14:22 |
| ogra | well, for the true fix we need another linux upload | 14:22 |
| ogra | i dont think the commit was uploaded yet | 14:22 |
| ogra | so wait with cheering :) | 14:23 |
| ogra | current binary has still the A2 workaround | 14:23 |
| GrueMaster | Nothing else to report at this time. | 14:24 |
| ogra | NCommander, oh, wasnt there a c/o for asac from two meetings ago ? | 14:24 |
| NCommander | ogra: possibly | 14:25 |
| * ogra just remembered that qt upstream conversation thing | 14:25 | |
| NCommander | [topic] ARM Porting/FTBFS status (NCommander, dyfet) | 14:25 |
| MootBot | New Topic: ARM Porting/FTBFS status (NCommander, dyfet) | 14:25 |
| ogra | i commented on dyfet_away's apr bug | 14:25 |
| NCommander | ogra: oh, that.that requires anoffline conversation until we can bring it back here | 14:25 |
| ogra | his patch changes a strin thats unecessary | 14:25 |
| ogra | if thats fixed i'll upload apr for him | 14:25 |
| NCommander | [action] NCommander and asac to discuss qt qreal issue | 14:25 |
| MootBot | ACTION received: NCommander and asac to discuss qt qreal issue | 14:25 |
| ogra | beyond that openjdk causes more and more fallout | 14:26 |
| NCommander | ogra: huh?, that was a buildd sucking issue | 14:26 |
| ogra | NCommander, what ? | 14:26 |
| NCommander | it builds properly locally | 14:26 |
| NCommander | ogra: apr builds fine without modification expect on the buildds | 14:26 |
| ogra | its a glibc issue as i understood lool | 14:26 |
| ogra | and a bug against glibc is filed | 14:27 |
| * NCommander looks at the log | 14:27 | |
| asac | NCommander: did you manage to talk to thiago at akademy about the soname (for qreal)? | 14:27 |
| NCommander | asac: I did, hence the part where we need to talk :-) | 14:27 |
| NCommander | asac: 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 notes | 14:28 |
| ogra | so the qt4-x11 ftbfs is the same issue i guess ? | 14:28 |
| ogra | which tears down kde again | 14:28 |
| asac | NCommander: ok cool. catch me tomorrow | 14:28 |
| NCommander | ogra: qt4-x11 is an ICE | 14:29 |
| ogra | oh, right | 14:29 |
| NCommander | ogra: and kdebindings is FTBFS still (though I know why its FTBFS (someone removed the support code to make ARM work)) | 14:29 |
| ogra | well, wouldnt the upstream fix change that ? | 14:29 |
| NCommander | ogra: your assuming I've made the change upstream yet :-) | 14:30 |
| ogra | i'm not assuming anything :) | 14:30 |
| ogra | thus the question mark above | 14:30 |
| NCommander | ogra: 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 to | 14:31 |
| ogra | yeah, all fine, no need for excuses :) | 14:32 |
| NCommander | ogra: heh | 14:32 |
| NCommander | [topic] ARM Image Status (ogra, NCommander) | 14:32 |
| MootBot | New Topic: ARM Image Status (ogra, NCommander) | 14:32 |
| ogra | we have images ! | 14:33 |
| ogra | :) | 14:33 |
| ogra | still | 14:33 |
| NCommander | they exist. | 14:33 |
| * NCommander ducks | 14:33 | |
| ogra | yeah | 14:33 |
| NCommander | hrm | 14:33 |
| ogra | still lots of small glitches etc | 14:33 |
| ogra | but they generally work | 14:33 |
| ogra | i'd indeed appreciate more testing and bug reports | 14:33 |
| NCommander | ogra: looks like our preinstalled image support code works nicely | 14:34 |
| NCommander | ogra: got anything else to add? | 14:34 |
| ogra | well, i'D like to see more SD crads being tested | 14:35 |
| GrueMaster | How many more? I have 4. | 14:35 |
| ogra | and i'm currently experimenting with a progressbar for resizing | 14:35 |
| rsalveti | I'll also help with testing when I get my boards | 14:35 |
| ogra | rsalveti, that was a secret hint for NCommander :) | 14:35 |
| ogra | to also test on his board | 14:35 |
| rsalveti | ogra: nice, progress bar is always good :-) | 14:36 |
| ogra | rsalveti, i know you will test once you have the HW :) | 14:36 |
| rsalveti | ;-) | 14:36 |
| ogra | yeah, i just found that resize2fs has a -p option | 14:36 |
| ogra | just need to test how to translate that to plymouth | 14:36 |
| ogra | or at least to a text mode | 14:36 |
| NCommander | ogra: fun with pipes? | 14:36 |
| ogra | yeah, something like that | 14:37 |
| ogra | and screen scraping or so | 14:37 |
| NCommander | ogra: you may just want to patch resize2fs to actually do something like the fsck -F option worse case scenario | 14:37 |
| ogra | well, i havent seen the progressbar yet | 14:37 |
| ogra | i'm still playing with the code atm | 14:38 |
| ogra | possible that its sufficient | 14:38 |
| ogra | anyway, nothing else about images | 14:38 |
| NCommander | [topic] Any Other Business | 14:38 |
| MootBot | New Topic: Any Other Business | 14:38 |
| rsalveti | I can talk about the rootstock stuff now | 14:38 |
| * NCommander points at the blank weekly reports section of the meeting from last week | 14:38 | |
| GrueMaster | Will there be a meeting next week during the sprint? | 14:39 |
| NCommander | GrueMaster: nope | 14:39 |
| rsalveti | I finally got an image created as user, and posted my branch at https://code.edge.launchpad.net/~rsalveti/project-rootstock/no-root | 14:39 |
| rsalveti | ogra: can you take a look later? | 14:39 |
| ogra | NCommander, can you add a rootstock section to the agenda for next meeting = | 14:39 |
| ogra | ? | 14:39 |
| ogra | NCommander, so rsalveti has his own slot | 14:39 |
| rsalveti | ogra: yeah, that would help | 14:39 |
| ogra | rsalveti, will do | 14:40 |
| rsalveti | had some issues with qemu, fuseext2 and genext2fs | 14:40 |
| rsalveti | but after finding the correct options, I just got the qemu bug | 14:40 |
| NCommander | np | 14:40 |
| rsalveti | https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/604872 | 14:40 |
| ogra | fusext2 was supposed to be researched by dyfet_away | 14:40 |
| ubottu | Launchpad bug 604872 in qemu-kvm (Ubuntu) "qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm" [Undecided,New] | 14:40 |
| rsalveti | most of the time I get a seg fault on it =\ | 14:41 |
| rsalveti | so I created a workaround at rootstock code, to run the vm more than one time | 14:41 |
| rsalveti | and with that I'm able to create the rootfs most of the time | 14:41 |
| rsalveti | so now I'll wait ogra review, finish it and move to the other rootstock bugs and patches | 14:41 |
| ogra | did you test the rootfs afterwards ? | 14:42 |
| rsalveti | and I'm running the image at my b5 beagleboard :-) | 14:42 |
| ogra | to make sure the crash doesnt cause breakage in the image | 14:43 |
| ogra | k | 14:43 |
| rsalveti | ogra: yeah, did run quite fine, at least the almost 10 times I tested | 14:43 |
| rsalveti | because the seg fault happens just after the debootstrap second stage | 14:43 |
| rsalveti | probably when mounting proc or sysfs | 14:43 |
| ogra | strange | 14:44 |
| rsalveti | so I'm now checking if the bootstrap script is there on the installer script, and if not just continue | 14:44 |
| rsalveti | and at the end you'll get the image | 14:44 |
| ogra | try to add some schos in the installer script so you can see the exact point | 14:44 |
| ogra | *echos | 14:44 |
| rsalveti | ogra: yep, quite strange | 14:44 |
| rsalveti | ogra: I did this, and even the echo got the seg fault some times | 14:44 |
| ogra | ouch | 14:45 |
| rsalveti | it seems that the debootstrap lets qemu in an unstable situation | 14:45 |
| ogra | i wonder if its a kernel issue of the vm kernel | 14:45 |
| ogra | would require some qemu testing with an image | 14:45 |
| rsalveti | ogra: I'd also like to test a different kernel to see if this could be the issue | 14:45 |
| rsalveti | but still needs to find/build another one | 14:45 |
| rsalveti | but that's all from my side | 14:47 |
| NCommander | ok, I think I can close the meeting | 14:48 |
| NCommander | any objections? | 14:48 |
| ogra | count down :) | 14:48 |
| NCommander | 3 | 14:48 |
| NCommander | 2 | 14:48 |
| NCommander | 1 | 14:48 |
| NCommander | 0 | 14:49 |
| NCommander | -1 | 14:49 |
| NCommander | -2 | 14:49 |
| NCommander | -3 | 14:49 |
| NCommander | :-) | 14:49 |
| NCommander | #endmeeting | 14:49 |
| MootBot | Meeting finished at 08:49. | 14:49 |
| rsalveti | :P | 14:49 |
| dyfet_away | oh wow got back from doctor just in time for the end :( | 14:49 |
| === dyfet_away is now known as dyfet | ||
| kees | \o | 14:57 |
| pitti | hello | 14:58 |
| cjwatson | hi | 15:01 |
| cjwatson | no Keybuk? | 15:02 |
| mdz | haven't seen him | 15:03 |
| tgardner | I just received an email from him a bit ago | 15:03 |
| cjwatson | I've SMSed him | 15:03 |
| tgardner | 20 minutes ago | 15:03 |
| cjwatson | he's buried in something else; another volunteer to chair? | 15:04 |
| cjwatson | is sabdfl going to be here? | 15:04 |
| mdz | assume no | 15:06 |
| * pitti is in a mumble meeting as well, so hard for me to chair right now | 15:06 | |
| mdz | my previous call is running over as well | 15:06 |
| cjwatson | mdz: can we just shunt forward a fortnight in the cycle, which would make it your turn to chair? | 15:06 |
| mdz | I looked at the agenda yesterday and it didn't appear to have been touched since the last meeting | 15:06 |
| cjwatson | I added two items to it yesterday | 15:06 |
| cjwatson | and there was already one from jono | 15:07 |
| mdz | I added the jono one when I looked | 15:07 |
| mdz | but he's on holiday today anyway | 15:07 |
| pitti | jono said he's on vac today | 15:07 |
| cjwatson | ok, I'll chair sisnce nobody else seems to want to | 15:07 |
| cjwatson | #startmeeting | 15:07 |
| MootBot | Meeting started at 09:07. The chair is cjwatson. | 15:07 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 15:07 |
| cjwatson | [TOPIC] Action review | 15:07 |
| MootBot | New Topic: Action review | 15:07 |
| cjwatson | of the items from two meetings ago, the only one not done was | 15:08 |
| cjwatson | cjwatson to write up 2010-06-15 minutes | 15:08 |
| cjwatson | I did that yesterday | 15:08 |
| cjwatson | from last meeting: | 15:08 |
| cjwatson | kees to check up on 174375 with bdmurray | 15:08 |
| kees | I've been talking with him about that; it's under way. | 15:08 |
| cjwatson | mdz to follow up with doko on toolchain, ix86 performance | 15:08 |
| cjwatson | kees: do we need to keep it on our agenda? | 15:09 |
| kees | they're discussing the bug at the LP sprint, so it will likely turn into a real plan soon | 15:09 |
| kees | cjwatson: probably not; I'll keep it moving with the LP team. | 15:09 |
| cjwatson | ok | 15:09 |
| cjwatson | mdz: any word from doko? | 15:10 |
| mdz | cjwatson: yes, he replied to t-b@ | 15:10 |
| mdz | in fact I think this action was closed at the last meeting | 15:10 |
| cjwatson | ok | 15:11 |
| cjwatson | Review PostReleaseApps/Process (jono) | 15:11 |
| cjwatson | oops | 15:11 |
| cjwatson | [TOPIC] Review PostReleaseApps/Process (jono) | 15:11 |
| doko | test results and fixes are there, we should be ready to switch, but maybe lets discuss this on Mon | 15:11 |
| MootBot | New Topic: Review PostReleaseApps/Process (jono) | 15:11 |
| cjwatson | do we want to discuss this today, given that jono is away? he sent mail asking for feedback, I don't see any on the list | 15:12 |
| mdz | I've been involved with reviewing it already | 15:12 |
| mdz | so I've already given my feedback and it's been mostly incorporated I think | 15:12 |
| cjwatson | I confess that I am not yet ready to vote on it | 15:13 |
| pitti | me neither, I'm afraid | 15:13 |
| mdz | actions to review by next meeting? | 15:13 |
| pitti | I'll put it to my TODO list to review it by next meeting | 15:13 |
| cjwatson | and perhaps to vote by e-mail | 15:13 |
| cjwatson | I'll take an action to review and chivvy | 15:13 |
| pitti | email vote WFM, too | 15:13 |
| cjwatson | [ACTION] cjwatson to drive review/vote on PostReleaseApps/Process | 15:13 |
| MootBot | ACTION received: cjwatson to drive review/vote on PostReleaseApps/Process | 15:13 |
| cjwatson | let's move on, my apologies for not being better prepared there | 15:14 |
| cjwatson | [TOPIC] Karmic kernel packaging changes (cjwatson) | 15:14 |
| MootBot | New Topic: Karmic kernel packaging changes (cjwatson) | 15:14 |
| cjwatson | I invited kernel folks here today to discuss this; I see tgardner and smb | 15:14 |
| smb | I am here | 15:14 |
| tgardner | here is the discussion link: https://lists.ubuntu.com/archives/kernel-team/2010-July/011545.html | 15:14 |
| mdz | welcome, kernel folks | 15:15 |
| cjwatson | I was just about to start typing a summary; thanks for saving me the effort. :) | 15:15 |
| pitti | smb: the other day we talked about providing a more stripped down diff which filters out the renames; is that available somewhere? | 15:15 |
| cjwatson | my 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 member | 15:15 |
| smb | pitti, I thought you were on cc of that email apw sent | 15:16 |
| cjwatson | I advised that the TB would be the appropriate body to take a decision | 15:16 |
| mdz | I think I recall the previous iteration of this discussion | 15:16 |
| mdz | where there was a question about whether substantial packaging changes were OK for SRU | 15:16 |
| pitti | smb: I was CC'ed to a thread, yes; but I didn't see a filtered patch? | 15:16 |
| smb | pitti, Ok, I might resend it | 15:16 |
| mdz | I 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 do | 15:17 |
| smb | pitti, There was a diff inlined | 15:17 |
| pitti | my 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 expensive | 15:17 |
| mdz | i.e. the most important aspects of the packaging can be tested for correctness | 15:17 |
| cjwatson | in 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 wide | 15:17 |
| tgardner | mdz, that has been my philosophy | 15:17 |
| pitti | and I can't vouch for that, so I don't feel like putting my approval stamp on it TBH | 15:17 |
| mdz | I have not seen any of the proposed changes in this case, so I can't comment on what the risks are | 15:18 |
| tgardner | pitti, these packaging changes won't affect compiler flags. | 15:18 |
| mdz | that link doesn't seem to have information on the actual code changes | 15:18 |
| smb | pitti, Though most if not all changes are outside the upstream kernel build infrastructure, so bulding itself would not be affected | 15:18 |
| mdz | e.g. a debdiff | 15:18 |
| pitti | smb: ah no, I didn't get a mail from apw, I was just on tgardner's thread | 15:18 |
| cjwatson | I can produce a debdiff given a moment | 15:18 |
| smb | Our test was to debdiff all binary packages to see those contain the same files | 15:19 |
| pitti | http://launchpadlibrarian.net/50067689/linux_2.6.31-21.59_2.6.31-22.61.diff.gz | 15:19 |
| MootBot | LINK received: http://launchpadlibrarian.net/50067689/linux_2.6.31-21.59_2.6.31-22.61.diff.gz | 15:19 |
| tgardner | the 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 |
| cjwatson | I am curious what changes the kernel team would feel to be unacceptable in packaging | 15:20 |
| tgardner | I guess changes that affected the content of the binary packages produced? | 15:20 |
| tgardner | does that make sense? | 15:21 |
| smb | pitti, forward just sent to you kees cjwatson mdz | 15:21 |
| mdz | smb: thanks | 15:21 |
| kees | cool | 15:21 |
| mdz | if it's possible to get a bzr-style diff which doesn't exaggerate the amount of change due to renames, that would be ideal | 15:22 |
| tgardner | mdz, we'd have to work on that, so not likely by the end of this meeting. | 15:22 |
| cjwatson | except these changes do seem to affect the content in certain ways, for example linux-image-debug -> dbgsym | 15:22 |
| smb | mdz, I am not sure we can provide bzr style, but the mail forwarded contains hints about similarity | 15:23 |
| mdz | tgardner: that's OK; I think the TB should be concerned with the general principle here, rather than this specific changeset | 15:23 |
| tgardner | I'd also like to point out tat we intend to do this for Hardy (eventually) | 15:23 |
| apw | i believe the email smb just forwarded has the git diff which has the renames in it | 15:23 |
| mdz | hmm, package renames could be problematic | 15:23 |
| smb | mdz, not package renames | 15:23 |
| smb | mdz, renamed fieles in the infrastructure | 15:23 |
| cjwatson | linux-image-debug (-> dbgsym) ends up on ddebs.ubuntu.com rather than in the archive | 15:23 |
| cjwatson | -Package: linux-image-debug-2.6.31-21-generic | 15:24 |
| cjwatson | +Package: linux-image-2.6.31-22-generic-dbgsym | 15:24 |
| apw | cjwatson, though the current implementation is also pushing those over to ddebs | 15:24 |
| smb | cjwatson, Ok, that is a change that we were actually asked to do | 15:24 |
| cjwatson | apw: what I'm trying to get at is the truth | 15:24 |
| cjwatson | I'm being told "no changes in the content of the binary packages" <small>except for this one</small> | 15:24 |
| pitti | right, that ddeb rename is fine | 15:24 |
| cjwatson | which other ones are we missing? :-) | 15:24 |
| smb | no package other than ddebs afaik. apw? | 15:25 |
| cjwatson | I don't have a problem with that particular change given that pitti is the ddeb-meister and asked for it | 15:25 |
| pitti | so 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 |
| apw | cjwatson, after hardy those packages have always gone to ddebs regardless of names, the first is bodged specifically as i understands things | 15:25 |
| cjwatson | apw: 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 zero | 15:26 |
| smb | pitti, The main reason is that builds have evolved into being the same but sometimes with slight differences | 15:26 |
| smb | and those differences are error prone | 15:26 |
| smb | especially as Lucid arm trees are based on Karmic kernel versions | 15:26 |
| apw | cjwatson, yep i get your point, and am trying to work out how to answer your question without making things less clear | 15:27 |
| pitti | if 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 |
| smb | So the goal was to have one build infrastructure that we can get eventually to be applied to all releases | 15:27 |
| tgardner | smb means with each release we've accumulated some cruft, and now we're trying to fix some of that cruft. | 15:27 |
| pitti | even 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 stables | 15:27 |
| cjwatson | nobody else gets to update their cruft in stable releases, though; what the TB needs to consider is why the kernel is different | 15:28 |
| mdz | pitti: right, hence my feeling that we should focus on the general principle instead | 15:28 |
| cjwatson | (IMO) | 15:28 |
| apw | the update commit contains a changelog fragment u | 15:28 |
| mdz | and provide some guidance to the SRU team on how to handle situations like this | 15:28 |
| pitti | and given that karmic isn't LTS and 8 months old, it should not get that much changes any more | 15:28 |
| apw | indicating which changes are carried over | 15:28 |
| tgardner | cjwatson, because we have a dozen (or more) source code packages? | 15:28 |
| mdz | I 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 stable | 15:28 |
| cjwatson | for 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 uphold | 15:29 |
| cjwatson | so I want to go through the proper process | 15:29 |
| mdz | that sounds reasonable enough | 15:30 |
| mdz | so the question here is, under what circumstances should substantive packaging changes be permissible in SRU? | 15:30 |
| mdz | (if any) | 15:30 |
| smb | Probably 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 maintainable | 15:30 |
| kees | as far as compiler flags, etc -- both old an new packages could be rebuilt with V=1 and the build logs compared... | 15:30 |
| mdz | kees: unless they compile in parallel, of course | 15:31 |
| smb | which we do | 15:31 |
| apw | though a sort could fix any ordering constraints on the results | 15:31 |
| kees | mdz: the security team has tools that handle that comparison pretty well. | 15:31 |
| mdz | kees: oh, neat | 15:31 |
| cjwatson | mdz: 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 |
| mdz | kees: share :-) | 15:31 |
| cjwatson | the kernel team is saying, AIUI, that the error rate from not having their substantive packaging changes is riskier than leaving things as they are | 15:32 |
| cjwatson | I can respect that position, but I would like not to be put in the position where 100 other maintainers show up asking for similar things | 15:32 |
| * smb nods | 15:32 | |
| cjwatson | because we won't be able to cope | 15:32 |
| kees | mdz: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head:/build-tools/diff-reorder | 15:33 |
| mdz | I 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 that | 15:33 |
| cjwatson | perhaps, for the time being, we should simply limit this explicitly to the kernel, with a rationale | 15:34 |
| mdz | if we set some guidelines, I think that would keep the floodgates closed | 15:34 |
| cjwatson | I don't want it to be an option advertised for everyone to use | 15:34 |
| kees | (with http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head:/build-tools/buildlog-compare) | 15:34 |
| pitti | cjwatson: me neither | 15:34 |
| cjwatson | it's perhaps also worth noting that the kernel is one of the biggest users of stable updates | 15:34 |
| smb | I think there isn't any package being that complex either | 15:35 |
| kees | firefox falls into this category too ... | 15:35 |
| cjwatson | smb: you'd be surprised ... | 15:35 |
| pitti | and we already are a lot less strict with kernel changes than for other SRUs, so in practice it's already special | 15:35 |
| cjwatson | (along with the desktop, but they generally don't update packaging) | 15:35 |
| kees | but it's doing even larger updates | 15:35 |
| cjwatson | the rationale for firefox is, similarly, that the risk of not doing so is greater | 15:35 |
| cjwatson | more or less | 15:35 |
| * kees nods | 15:36 | |
| mdz | cjwatson: a decision on the kernel in general would be better than deciding on this change specifically | 15:36 |
| mdz | but it doesn't smell right | 15:36 |
| cjwatson | the change, or the approach? | 15:37 |
| mdz | the approach | 15:37 |
| mdz | if there are reasons why the kernel warrants such an exception, it should apply to other packages which have the same reasons | 15:37 |
| mdz | and if we don't agree on what those reasons are, the kernel shouldn't get an exception just because it's the kernel | 15:38 |
| mdz | the idea of the kernel having looser change control, while being one of our most critical components, gives me the willies | 15:38 |
| mdz | (especially when pitti says that this is already the case in practice) | 15:38 |
| tgardner | mdz, don't forget that is kernel(s), not just the one. there are a bunch of them we're producing. | 15:39 |
| cjwatson | the 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 point | 15:39 |
| mdz | yes, and I accept that when there is a lot of divergence in the packaging, this increases the risk of mistakes being made in updates | 15:39 |
| mdz | has the SRU team said no to this? | 15:39 |
| pitti | the 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 in | 15:39 |
| mdz | is this an appeal, or a request for guidance? | 15:39 |
| cjwatson | I said no, and that the kernel team could appeal to the TB | 15:40 |
| mdz | I see | 15:40 |
| cjwatson | specifically I said no because I felt that it was outside my range of permitted discretion | 15:40 |
| cjwatson | more perhaps than because I thought it was intrinsically wrong | 15:40 |
| tgardner | I contend that it'll reduce the number of mistakes we might make if packaging is common across all of the kernel branches. | 15:40 |
| pitti | same 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 |
| pitti | s/:/"/ | 15:40 |
| mdz | the diffstat from apw looks pretty manageable | 15:41 |
| pitti | with the renamings it's a little easier, but still a "{debian.master => debian}/rules.d/0-common-vars.mk" doesn't say muc | 15:41 |
| pitti | since it puts a previously inert file into action | 15:41 |
| cjwatson | so reasons I can think of why the kernel is special: | 15:42 |
| cjwatson | * high flow of changes through updates | 15:42 |
| cjwatson | * many different packages synchronised across multiple releases | 15:42 |
| cjwatson | * significant degree of autogeneration in packaging | 15:42 |
| cjwatson | (in terms of rationale for the change, not in terms of the change itself) | 15:42 |
| cjwatson | what else? | 15:42 |
| pitti | "many maintainers" perhaps? | 15:42 |
| apw | pitti, actually it moves a file which the reference also changes from the old to the new | 15:42 |
| cjwatson | I don't know of any other packages meeting those descriptions right now | 15:42 |
| mdz | cjwatson: I'd say specifically a high flow of changes across multiple releases | 15:42 |
| pitti | "training new maintainers on the packaging" | 15:42 |
| apw | "multiple versions in each release" | 15:43 |
| smb | pitti, Oh yeah. Good one as well | 15: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 |
| mdz | cjwatson: I think we need to establish what the question is that we're voting on | 15:43 |
| mdz | if it's "does the SRU team have the authority to decide this?" then that is an easy yes | 15:44 |
| mdz | so 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 here | 15:44 |
| mdz | (easy yes - for me) | 15:45 |
| cjwatson | the 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 TB | 15:45 |
| cjwatson | such as the micro-release exceptions stuff | 15:45 |
| pitti | I had thought it was "extend the SRU policy to allow repackaging for the kernel"? | 15:45 |
| cjwatson | pitti: *nod* | 15:45 |
| smb | pitti, Actually not repackaging but change the build infrastructure as an SRU | 15:45 |
| cjwatson | SRU policy changes have always gone to the TB before | 15:45 |
| cjwatson | smb: the wide term for this in the distribution is repackaging | 15:46 |
| smb | ok | 15:46 |
| cjwatson | (when the changes are this substantial) | 15:46 |
| cjwatson | but if you feel the term is emotive, we can choose a different one | 15:46 |
| pitti | smb: right, I consider the build infrastructure part of the packaging | 15:46 |
| pitti | but calling it "change build system" WFM | 15:47 |
| smb | No, I probably just had a different understanding of packaging | 15:47 |
| cjwatson | packaging> stuff under debian/ | 15:47 |
| cjwatson | well, debian*/ in your case :) | 15:47 |
| smb | Right: :) | 15:47 |
| smb | I can live with that | 15:47 |
| cjwatson | I'd like a straw-poll to check that the board in general, well, isn't implacably opposed to this change | 15:48 |
| mdz | I 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 benefits | 15:48 |
| cjwatson | I'm willing to draft such a policy if the board feels that it would support it | 15:49 |
| pitti | it would basically mean to put the SRU review into "blind mode" though | 15:49 |
| kees | I would support it if it included the "why the kernel is special" list as part of the guidelines for what makes an exception | 15:49 |
| mdz | I agree with cjwatson that we don't want to open this up generally | 15:49 |
| pitti | so we need to see if that's considered acceptable | 15:49 |
| cjwatson | pitti: "blind mode"> could you expand on that? | 15:50 |
| mdz | pitti: why? | 15:50 |
| smb | pitti, Probably requiring some defined guidlines on what is required to provide as test that this changes are acceptable | 15:50 |
| pitti | I can't look at the delta and confirm that the changes are safe and don't introduce regression potential | 15:50 |
| mdz | pitti: don't you, in some cases, rely on other sources of information (such as testing) to confirm that changes are safe? | 15:51 |
| cjwatson | I'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 evidence | 15:51 |
| apw | pitti, 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 benign | 15:51 |
| pitti | the 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 rest | 15:51 |
| apw | cjwatson, and from our side we are more than willing to do whatever we need to to make your team comfortable | 15:51 |
| pitti | apw: that won't spot compiler flags, configuration changes, or weird linker errors, though | 15:52 |
| apw | knowing that you cannot understand the packaging at the level of detail that we might | 15:52 |
| pitti | so while a binary debdiff is important, it's not really sufficient | 15:52 |
| cjwatson | kees' toolset for log comparison ought to help | 15:52 |
| apw | pitti, if any of those were different its not clear how the binaries could be identicle | 15:52 |
| kees | it's not perfect, but it helps. | 15:52 |
| pitti | so, I'm not saying that I totally oppose to what I called "blind mode" above, but we need to be aware of the fact | 15:52 |
| mdz | pitti: 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 |
| apw | pitti, in the comparisons i did when doing the changes in later releases they had the same md5sum | 15:52 |
| cjwatson | given 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 architectures | 15:53 |
| mdz | pitti: in the kernel case, the configuration does get bundled into the package, so a binary debdiff would catch that, no? | 15:53 |
| cjwatson | and trust to testing to catch errors beyond that | 15:53 |
| pitti | apw: comparing build logs with kees script plus binary debdiff together sounds rather safe, WDYT? | 15:53 |
| mdz | I agree | 15:53 |
| pitti | mdz: oh, how so? | 15:53 |
| mdz | pitti: I assume you're talking about the build configuration, i.e. /boot/config-`uname -r` | 15:54 |
| pitti | mdz: debdiff on .debs just shows the file additions/removals, not the file content diffs, after all | 15:54 |
| pitti | mdz: yes, that | 15:54 |
| mdz | pitti: oh, of course. yes, naturally the contents need to be compared as well | 15:54 |
| apw | pitti, right we have beeing doing the binary debdiffs internally before submission, clearly you cannot see that with the current process | 15:54 |
| cjwatson | yes, it would have to be a content comparison of the text files | 15:54 |
| pitti | apw: 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 debdiff | 15:55 |
| mdz | I forgot that debdiff didn't show the changes to files in the binary packages | 15:55 |
| cjwatson | ok, I think we have something approaching consensus. how about I go off and draft a chunk of policy text for this? | 15:55 |
| cjwatson | no offence to anyone but I really don't want ever to have to have this conversation again ;-) | 15:55 |
| kees | :) | 15:55 |
| pitti | ++ | 15:55 |
| apw | pitti, 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 honest | 15:55 |
| mdz | +1 | 15:55 |
| mdz | cjwatson: 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 |
| pitti | so, 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 us | 15:56 |
| cjwatson | perhaps, but maybe over beer | 15:56 |
| smb | Actually I was for now to ask cjwatson to reject the current uploads | 15:56 |
| cjwatson | we're running out of time in this meeting | 15:56 |
| mdz | I want to support a strong SRU team which can push back on developers on behalf of users | 15:56 |
| mdz | ok | 15:57 |
| pitti | another thing to consider is that very few developers still run karmic | 15:57 |
| pitti | (i. e. the folks who would come to us and tell us about regressions) | 15:57 |
| pitti | wrt. the "spot regressions in proposed" part | 15:58 |
| cjwatson | my last item is very quick, and then perhaps we can take the rest to e-mail given that we have rough consensus here | 15:58 |
| smb | pitti, Just to say that but Lucid fsl-imx51 is Karmic kernel | 15:58 |
| cjwatson | [TOPIC] DMB member replacement (cjwatson) | 15:58 |
| MootBot | New Topic: DMB member replacement (cjwatson) | 15:58 |
| cjwatson | The DMB has received a resignation note from Richard Johnson | 15:59 |
| cjwatson | I'm ashamed to say I have no idea of the procedure for replacing him | 15:59 |
| cjwatson | Do 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 boards | 16:00 | |
| mdz | we bootstrapped DMB by double-booking the TB | 16:00 |
| mdz | and then solicited nominations from developers | 16:00 |
| mdz | i.e. developers were nominated by their peers, and then there was a general election | 16:01 |
| pitti | IMHO we should do the same: advertise the vacancy on u-d-a@ and then vote | 16:01 |
| mdz | agreed | 16:01 |
| cjwatson | OK, I'll sort that out then, thanks | 16:02 |
| mdz | I think the DMB itself can manage the election this time | 16:02 |
| cjwatson | sucks to be us ;-) | 16:02 |
| cjwatson | [TOPIC] AOB | 16:02 |
| MootBot | New Topic: AOB | 16:02 |
| cjwatson | ok, that'd be nothing then | 16:04 |
| cjwatson | #endmeeting | 16:04 |
| MootBot | Meeting finished at 10:04. | 16:04 |
| cjwatson | thanks all, I think this was productive | 16:04 |
| pitti | thanks everyone | 16:04 |
| JFo | o/ | 17:58 |
| cnd | o/ | 17:58 |
| lag | o/ | 17:58 |
| * manjo zooms in | 17:58 | |
| * JFo mans the flak cannon | 17:58 | |
| JFo | :) | 17:58 |
| * smb looks with one eye | 17:59 | |
| jjohansen | \o | 17:59 |
| bjf | #startmeeting | 18:00 |
| MootBot | Meeting started at 12:00. The chair is bjf. | 18:00 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 18:00 |
| bjf | [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting | 18:00 |
| MootBot | LINK received: https://wiki.ubuntu.com/KernelTeam/Meeting | 18:00 |
| bjf | [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick | 18:00 |
| MootBot | LINK received: https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick | 18:00 |
| bjf | # | 18:00 |
| bjf | # NOTE: '..' indicates that you are finished with your input. | 18:00 |
| bjf | # | 18:00 |
| bjf | [TOPIC] ARM Status (lag) | 18:00 |
| MootBot | New Topic: ARM Status (lag) | 18:00 |
| lag | - Marvel (mvl-dove) | 18:00 |
| lag | - Nothing new this week | 18:00 |
| lag | - Freescale (fsl-imx51) | 18:00 |
| lag | - Nothing new this week | 18: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 modules | 18:00 |
| lag | - PATCH : ti-omap4 patches posted for review - sebjan requested to do the same | 18:00 |
| lag | - PATCH : Several patches from TI have been reviewed and merged into our kernel | 18:00 |
| lag | - ON GOING : B593650 was once again reproducible - this is next on mpoirier's hit-list | 18:01 |
| lag | - ON GOING : B601226 patch has been sent upstream - awaiting feedback | 18:01 |
| lag | - ON GOING : B592295 a patch and RFC has been set out by TI - awaiting feedback | 18:01 |
| lag | - ON GOING : B477106 is sleeping until further notice | 18:01 |
| lag | - FIXED : B594382 was fixed in rc4 - was probing for daisy-chain event rather than daisy-chain en bit | 18:01 |
| lag | .. | 18:01 |
| bjf | [TOPIC] Release Metrics: (JFo) | 18:01 |
| MootBot | New Topic: Release Metrics: (JFo) | 18:01 |
| JFo | Bugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs) | 18:01 |
| JFo | Release 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 bugs | 18:02 |
| JFo | * 0 linux-ec2 bugs | 18:02 |
| JFo | * 0 linux-mvl-dove bugs | 18: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 bugs | 18:02 |
| JFo | * 0 linux-ec2 bugs | 18:02 |
| JFo | * 2 linux-mvl-dove bugs | 18: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 blueprints | 18: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=on | 18:02 |
| JFo | * Breakdown by status: | 18:02 |
| JFo | http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/ | 18:02 |
| JFo | .. | 18:02 |
| bjf | [TOPIC] Blueprint: kernel-maverick-apparmor (jjohansen) | 18:02 |
| bjf | [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor | 18:02 |
| MootBot | New Topic: Blueprint: kernel-maverick-apparmor (jjohansen) | 18:02 |
| MootBot | LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor | 18:02 |
| jjohansen | Bug #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 |
| jjohansen | Bug #602261 - looks to be AppArmor exacerbating Bug #600359. Have applied | 18:03 |
| jjohansen | a kernel patch that should reduce this by adjusting AA policy memory allocations, | 18:03 |
| jjohansen | and have also applied some patches to user space tools reduce memory usage. | 18:03 |
| jjohansen | Bug #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 |
| jjohansen | Next submit is queued, and ready to go out pending regression tests that are running on the updated rebase. | 18:03 |
| ubottu | Launchpad bug 599450 in linux (Ubuntu Maverick) "[apparmor] getattr handled incorrectly in 2.6.35-6.7" [High,New] https://launchpad.net/bugs/599450 | 18:03 |
| ubottu | Launchpad bug 602261 in linux (Ubuntu) "Thrashing and OOM during upgrade from 10.04 to Maverick" [High,Confirmed] https://launchpad.net/bugs/602261 | 18:03 |
| ubottu | Launchpad bug 600359 in ureadahead (Ubuntu Maverick) "ureadahead generating oom messages during boot." [Medium,Confirmed] https://launchpad.net/bugs/600359 | 18:03 |
| ubottu | Launchpad bug 581524 in Ubuntu Manual "string 392 missing, "you" and "your"" [Low,Fix committed] https://launchpad.net/bugs/581524 | 18:03 |
| jjohansen | .. | 18:03 |
| JFo | that last bug looks odd | 18:04 |
| JFo | .. | 18:04 |
| jjohansen | indeed that is right | 18:04 |
| bjf | [TOPIC] Blueprint: kernel-maverick-misc (apw) | 18:04 |
| bjf | [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc | 18:04 |
| MootBot | New Topic: Blueprint: kernel-maverick-misc (apw) | 18:04 |
| MootBot | LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc | 18:04 |
| apw | Nothing new to report. | 18:05 |
| apw | .. | 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-lts | 18:05 |
| MootBot | New Topic: Blueprint: kernel-maverick-new-kernel-on-lts (tgardner) | 18:05 |
| MootBot | LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts | 18:05 |
| bjf | Nothing 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-kernel | 18:05 |
| MootBot | New Topic: Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen) | 18:05 |
| MootBot | LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel | 18:05 |
| jjohansen | Received 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 |
| jjohansen | Have built a test kernel but haven't tested yet. | 18:05 |
| === zyga is now known as zyga_ | ||
| jjohansen | JFo: it was Bug #581525 | 18:06 |
| ubottu | Launchpad bug 581525 in apparmor (Ubuntu) "Lucid: system becomes unstable randomly, seems related with apparmor" [Undecided,New] https://launchpad.net/bugs/581525 | 18:06 |
| JFo | ah :) | 18:06 |
| jjohansen | .. | 18:06 |
| JFo | .. | 18:07 |
| bjf | [TOPIC] Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara) | 18:07 |
| bjf | [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review | 18:07 |
| MootBot | New Topic: Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara) | 18:07 |
| MootBot | LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review | 18:07 |
| ogasawara | Nothing new to report this week. | 18:07 |
| ogasawara | .. | 18:07 |
| bjf | [TOPIC] Blueprint: kernel-maverick-config-review (ogasawara) | 18:07 |
| bjf | [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-config-review | 18:07 |
| MootBot | New Topic: Blueprint: kernel-maverick-config-review (ogasawara) | 18:07 |
| MootBot | LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-config-review | 18:07 |
| ogasawara | Nothing new to report this week. | 18:07 |
| ogasawara | .. | 18:07 |
| bjf | [TOPIC] Blueprint: kernel-maverick-bug-handling (JFo) | 18:07 |
| bjf | [LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling | 18:07 |
| MootBot | New Topic: Blueprint: kernel-maverick-bug-handling (JFo) | 18:07 |
| MootBot | LINK received: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling | 18:07 |
| JFo | Location 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 |
| JFo | .. | 18:08 |
| bjf | [TOPIC] Blueprint: kernel-maverick-upstart (apw) | 18:08 |
| bjf | [LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart | 18:08 |
| MootBot | New Topic: Blueprint: kernel-maverick-upstart (apw) | 18:08 |
| MootBot | LINK received: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart | 18:08 |
| apw | Nothing new to report. | 18:08 |
| apw | .. | 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-automation | 18:08 |
| MootBot | New Topic: Blueprint: kernel-maverick-bios-test-automation (cking) | 18:08 |
| MootBot | LINK received: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bios-test-automation | 18:08 |
| bjf | no cking i guess | 18:09 |
| bjf | [TOPIC] Status: Maverick (ogasawara) | 18:09 |
| MootBot | New Topic: Status: Maverick (ogasawara) | 18:09 |
| ogasawara | The 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 |
| ogasawara | Alpha 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.html | 18:09 |
| ogasawara | [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone maverick-alpha-3 | 18:09 |
| ogasawara | .. | 18:09 |
| MootBot | LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-3.html | 18:09 |
| MootBot | LINK received: https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone maverick-alpha-3 | 18:09 |
| bjf | [TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb) | 18:11 |
| MootBot | New Topic: Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb) | 18:11 |
| smb | Dapper: 2.6.15-55.84 (security) | 18:11 |
| smb | Hardy: 2.6.24-28.71 (updates) | 18:11 |
| smb | Jaunty: 2.6.28-19.61 (security) | 18:11 |
| smb | Karmic: 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 |
| smb | Lucid: 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 done | 18: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 |
| smb | Security update is prepared and pending, waiting for Lucid proposed moving to | 18:11 |
| smb | updates. | 18:11 |
| smb | .. | 18:11 |
| smb | Err, actually | 18:12 |
| smb | Karmic uploads have been rejected on my request for now | 18:12 |
| smb | We try to restore normality if we know what that is anyway. | 18:12 |
| smb | .. | 18:12 |
| * apw laughs :) | 18:12 | |
| bjf | [TOPIC] Incoming Bugs: Regressions (JFo) | 18:12 |
| MootBot | New Topic: Incoming Bugs: Regressions (JFo) | 18:12 |
| JFo | Incoming Bugs | 18:12 |
| JFo | 59 Maverick Bugs (up 9) | 18:12 |
| JFo | 1049 Lucid Bugs (up 21) | 18:12 |
| JFo | Current 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 |
| JFo | I've been slack in moving Lucid bugs from r-p to r-r | 18:13 |
| JFo | but will get back on that week after next | 18:13 |
| JFo | .. | 18:13 |
| bjf | [TOPIC] Incoming Bugs: Bug day report (JFo) | 18:13 |
| MootBot | New Topic: Incoming Bugs: Bug day report (JFo) | 18:13 |
| JFo | The 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 expectatio | 18:13 |
| JFo | n 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 |
| JFo | there is a calendar item for the bug day tomorrow. | 18:13 |
| JFo | .. | 18:14 |
| bjf | [TOPIC] Open Discussion or Questions: Anyone have anything? | 18:14 |
| MootBot | New Topic: Open Discussion or Questions: Anyone have anything? | 18:14 |
| JFo | o/ | 18:14 |
| kamal | o/ | 18:14 |
| bjf | Please note that there will not be a Kernel team meeting next week. | 18:15 |
| bjf | JFo, go | 18:15 |
| JFo | There is a kernel triage chat tomorrow afternoon at 4PM EST | 18:15 |
| JFo | any Kernel Engineers interested in backing me up are welcome to attend :) | 18:15 |
| JFo | .. | 18:15 |
| ogasawara | https://wiki.ubuntu.com/UbuntuDeveloperWeek -> more info there | 18:15 |
| JFo | thanks ogasawara | 18:16 |
| JFo | :) | 18:16 |
| JFo | .. | 18:16 |
| bjf | kamal, go | 18:16 |
| kamal | bug 594837 (my usual topic) | 18:16 |
| ubottu | Launchpad 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/594837 | 18:16 |
| kamal | This 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 |
| kamal | Is it time for us to SRU this for Lucid or shall we continue to wait for stable? | 18:16 |
| apw | well lucid is now undergoing a security update, so it'll be a while before we can put anything new in there | 18:16 |
| smb | kamal, Right | 18:17 |
| kamal | may as well let it wait another week then :-) | 18:17 |
| kamal | .. | 18:17 |
| smb | kamal, Don't expect things to change next week | 18:17 |
| smb | kamal, There is a sprint going on... :) | 18:17 |
| kamal | ok, another *two* weeks then! ;-) | 18:17 |
| kamal | .. | 18:17 |
| smb | .. | 18:17 |
| bjf | thanks everyone | 18:17 |
| bjf | #endmeeting | 18:17 |
| MootBot | Meeting finished at 12:17. | 18:17 |
| JFo | thanks bjf | 18:17 |
| manjo | thanks bjf | 18:17 |
| kamal | thanks bjf | 18:17 |
| JFo | we are an efficient machine :) | 18:18 |
| kamal | yeah, fastest kernel team meeting ever | 18:18 |
| sommer | o// | 18:59 |
| SpamapS | o/ | 18:59 |
| hallyn | \o | 18:59 |
| ccheney | hi | 18:59 |
| jiboumans | o/ | 19:00 |
| jjohansen | \o | 19:01 |
| smoser | \o | 19:01 |
| * smoser is scribe | 19:01 | |
| ttx | o/ | 19:01 |
| jiboumans | smoser is chair! | 19:01 |
| hggdh | ~o~ | 19:01 |
| SpamapS | = | 19:02 |
| smoser | ok. so i guess we go. | 19:02 |
| smoser | #startmeeting | 19:02 |
| MootBot | Meeting started at 13:02. The chair is smoser. | 19:02 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 19:02 |
| smoser | https://wiki.ubuntu.com/ServerTeam/Meeting | 19:02 |
| * ttx bows to the Big Smoser | 19:03 | |
| === Ursinha is now known as Ursinha-afk | ||
| smoser | #topic Review ACTION points from previous meeting | 19:03 |
| ttx | [TOPIC] ... | 19:03 |
| smoser | [TOPIC] Review ACTION points from previous meeting | 19:03 |
| MootBot | New Topic: Review ACTION points from previous meeting | 19:03 |
| smoser | sommer waiting on mdke re: refresh issue | 19:03 |
| smoser | (that is our only action point) | 19:04 |
| smoser | sommer, ? | 19:04 |
| smoser | hm... sommer was here 5 minutes ago. | 19:04 |
| sommer | I think it was fixed | 19:04 |
| ttx | yes | 19:05 |
| sommer | yep it's updated | 19:05 |
| smoser | ok. | 19:05 |
| ttx | sommer: thanks ! | 19:05 |
| smoser | [TOPIC] Maverick development (jib) | 19:05 |
| MootBot | New Topic: Maverick development (jib) | 19:05 |
| jiboumans | I sent out the Alpha3 update to the mailinglist the other day | 19:05 |
| jiboumans | we're mostly on track for the high priority blueprints: http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-3.html | 19:05 |
| jiboumans | but we're very heavily loaded this cycle | 19:05 |
| jiboumans | Low prio blueprints are at risk of being postponed | 19:06 |
| jiboumans | none-feature stuff can be moved to the Betas, but feature development may have to wait until Maverick+1 for those | 19:06 |
| jiboumans | Apport hooks are a special case here and we have an agenda item for that further down | 19:06 |
| jiboumans | ttx, can you take us through the specific blueprints here? | 19:06 |
| ttx | the specific blueprints that may have to wait, or those that are Low and might need to be postponed ? | 19:07 |
| jiboumans | sorry, i meant the next item on the agenda | 19:07 |
| jiboumans | the subcycle tracking :) | 19:07 |
| ttx | ah! | 19:07 |
| * jiboumans notices his segway was no where nearly as smooth as imagined | 19:07 | |
| smoser | sorry | 19:08 |
| smoser | [TOPIC] Alpha3 subcycle status (ttx) | 19:08 |
| MootBot | New Topic: Alpha3 subcycle status (ttx) | 19:08 |
| ttx | I don't have so much to add to your brilliant analysis | 19:08 |
| SpamapS | jiboumans: more hand waving | 19:08 |
| ttx | I'd like to have more work items burnt | 19:08 |
| ttx | since it looks like we didn't do any work, while I know it's not the case | 19:08 |
| * SpamapS has got a fever, and the only prescription, is more hand waving | 19:08 | |
| jiboumans | seconding what ttx said; several people under 10% completion now is a red flag | 19:09 |
| SpamapS | ttx: 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 |
| ttx | i'll have discussions with spec assignees soon to confirm expectations | 19:09 |
| ttx | SpamapS: ack, next time try to decorrelate work and sponsoring wait to avoid that | 19:10 |
| ccheney | my uec provisioning work is very interrelated and i think i can probably get them all done quickly once i get one blocker resolved | 19:10 |
| ttx | package FOO / package BAR / get sponsoring for FOO and BAR | 19:10 |
| ttx | that allows to keep the ball smoothly rolling | 19:10 |
| jiboumans | ccheney: what's your blocking factor? | 19:10 |
| SpamapS | ttx: 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 |
| ttx | SpamapS: ah! that happens :) | 19:11 |
| ccheney | jiboumans, powerwake seems to need to write to the home directory but when running from apache2 has none, so it blows up | 19:11 |
| ccheney | jiboumans, 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 that | 19:11 |
| ccheney | i 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 problem | 19:12 |
| jiboumans | ccheney: i assume worst case you can workaround manually and continue testing? | 19:12 |
| ccheney | jiboumans, well to get it working in a packaged and tested manner i need to get that part resolved asap | 19:13 |
| ccheney | i emailed kirkland but it appears he may be off atm? | 19:13 |
| SpamapS | ttx: 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 |
| hallyn | yeah he's at a conf | 19:13 |
| jiboumans | ccheney: he's at a conference | 19:13 |
| ccheney | jiboumans, oh ok | 19:13 |
| ttx | SpamapS: ok, you seem to be on top of it | 19:14 |
| ccheney | is there a better version of uec.py somewhere other than kirkland's bzr repo? i wasn't sure if it was the main branch | 19:14 |
| ttx | smoser: that's all from me | 19:14 |
| smoser | [TOPIC] Weekly Updates & Questions for the QA Team (hggdh) | 19:15 |
| MootBot | New Topic: Weekly Updates & Questions for the QA Team (hggdh) | 19:15 |
| ttx | ccheney: I think kirkland has the most recent one | 19:15 |
| ttx | ccheney: it's a merge from several code bases, including mine | 19:15 |
| ccheney | ok | 19:15 |
| SpamapS | hggdh: Just a comment, I had no idea about the UEC rig, thanks for emailing that info! | 19:15 |
| jiboumans | hggdh: i see the blueprint for server-maverick-qa-workflow is progressing nicely | 19:16 |
| hggdh | jiboumans: yes... I had to stop for a while on the UEC testing to cater for the other tasks/blueprints | 19:16 |
| jiboumans | hggdh: is it worth a section in one of the coming meetings to introduce people to it (or some blog posts?) | 19:16 |
| hggdh | jiboumans: about the internal UEC rig ? | 19:17 |
| jiboumans | hggdh: server-maverick-qa-workflow | 19:17 |
| hggdh | ah. Sorry. Yes, it would be a good idea | 19:17 |
| jiboumans | hggdh: i trust you'll add it to the agenda when appropriate? | 19:18 |
| hggdh | jiboumans: albeit trusting me has been proved to be dangerous, yes, I will add it in | 19:18 |
| jiboumans | hggdh: already editing the blueprint with a WI ;) | 19:18 |
| hggdh | LOL | 19:18 |
| smoser | [ACTION] hggdh to discuss server-maverick-qa-workflow at future meeting | 19:19 |
| MootBot | ACTION received: hggdh to discuss server-maverick-qa-workflow at future meeting | 19:19 |
| jiboumans | hggdh: at my age, i can hardly trust my brain to remember things | 19:19 |
| smoser | moving on ? | 19:19 |
| * hggdh wonders about self's age... | 19:19 | |
| hggdh | I am done, smoser | 19:19 |
| smoser | [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen) | 19:19 |
| MootBot | New Topic: Weekly Updates & Questions for the Kernel Team (jjohansen) | 19:19 |
| jjohansen | sorry, can't seem to find my notes now | 19:20 |
| smoser | [TOPIC] Bug 597387: Maverick EC2 kernel issue | 19:21 |
| MootBot | New Topic: Bug 597387: Maverick EC2 kernel issue | 19:21 |
| ubottu | Launchpad bug 597387 in Ubuntu Maverick "pv-ops kernel only works in 3 or 4 zones in EC2" [High,Confirmed] https://launchpad.net/bugs/597387 | 19:21 |
| jiboumans | smoser: did you give me an update on that one yesterday? or was that unrelated? | 19:21 |
| jjohansen | so we received confirmation from Amazon contacts that pv-ops kernels work on EC2 and that they need xsave hypercall disabled | 19:21 |
| smoser | i dont think it was related. i dont recall anything yesterday. | 19:22 |
| smoser | jjohansen is on top of it. | 19:22 |
| jjohansen | I have built a pv-ops kernel but haven't tested it yet | 19:22 |
| smoser | so new kernel built and awating test in different regions ? | 19:22 |
| jjohansen | awaits any boot testing | 19:22 |
| jjohansen | I just haven't gotten that far yet | 19:23 |
| jjohansen | but that should happen this afternoon | 19:23 |
| smoser | great. | 19:23 |
| jjohansen | Bug #576066 | 19:23 |
| smoser | [TOPIC] Bug 576066: ums-cypress.ko missing from server installer | 19:23 |
| MootBot | New Topic: Bug 576066: ums-cypress.ko missing from server installer | 19:23 |
| ubottu | Launchpad bug 576066 in linux (Ubuntu Lucid) "ums_cypress missing from lucid server cd" [Low,In progress] https://launchpad.net/bugs/576066 | 19:23 |
| jjohansen | Tim has prioritized, and is taking care of this | 19:23 |
| smoser | [TOPIC] atop kernel patch | 19:24 |
| MootBot | New Topic: atop kernel patch | 19:24 |
| jiboumans | jjohansen: i only saw a handful of replies on the mailing-list | 19:24 |
| jjohansen | there hasn't been any more input on this yet | 19:24 |
| jjohansen | as it stands I don't see the kernel team picking up the patches | 19:25 |
| jiboumans | jjohansen: the use case highlighted of seeing what process is using bandwidth and the historical resource consumption are the two use cases i know | 19:25 |
| jjohansen | right | 19:25 |
| * ttx struggles a bit with his connection | 19:25 | |
| jiboumans | if there are alternate tools, that would be good to know of. i dont know any though | 19:25 |
| jiboumans | jjohansen: do you know of any that could provide that functionality instead? | 19:26 |
| jjohansen | jiboumans: I am not aware of any either | 19:26 |
| SpamapS | Honestly, 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 |
| jiboumans | jjohansen: ok, i'll chime in on the thread | 19:26 |
| SpamapS | atop is t3h awesome | 19:26 |
| jiboumans | it is | 19:26 |
| jjohansen | htop is better than top but I don't think it does | 19:26 |
| jjohansen | SpamapS, jiboumans: please chime in | 19:26 |
| SpamapS | nothing I've ever seen can tell me which process is doing which IO operations | 19:27 |
| jiboumans | doing so now | 19:27 |
| ttx | there is a EC2 performance issue filed against "Ubuntu on EC2", I'm trying (unsuccessfully) to get to its bug number | 19:27 |
| smoser | [ACTION] jiboumans to chime in on atop thread | 19:27 |
| MootBot | ACTION received: jiboumans to chime in on atop thread | 19:27 |
| smoser | bug 574910: I've been pinged again on this, per erichammond, it is preventing pe | 19:27 |
| smoser | ople from moving to lucid as perceived performance drop. It would be really nic | 19:27 |
| smoser | e to address it. even if we can't fix it, to clearly state that performance is | 19:27 |
| smoser | the same as it was or better (maybe some benchmarks?) | 19:27 |
| ubottu | Launchpad bug 574910 in linux-ec2 (Ubuntu) "High load averages on Lucid while idling" [Undecided,In progress] https://launchpad.net/bugs/574910 | 19:27 |
| jjohansen | jiboumans: also if this is really import let pete/tim know | 19:27 |
| smoser | (that is ttx's bug probably) | 19:27 |
| ttx | smoser: yes, thanks | 19:27 |
| SpamapS | We should also contact the KSLM author about this, which is probably "the right way" for atop to function | 19:27 |
| === dharman_ is now known as dharman | ||
| jjohansen | smoser: right, in my limited testing it looked like accounting but we need to do some more testing | 19:28 |
| jjohansen | SpamapS: KSLM? | 19:28 |
| SpamapS | www.headinthecloud.net and http://launchpad.net/kslm | 19:28 |
| SpamapS | Cole Crawford | 19:28 |
| jjohansen | ah, thanks | 19:29 |
| SpamapS | I spoke with him at UDS about some unrelated monitoring stuff.. | 19:29 |
| SpamapS | but I think kslm is an attempt to do what atop does, but in a less invasive way | 19:29 |
| jjohansen | okay, we need to look into it then | 19:30 |
| jiboumans | SpamapS: chime in on the thread? :) | 19:30 |
| smoser | ok. 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 |
| ubottu | Launchpad bug 574910 in linux-ec2 (Ubuntu) "High load averages on Lucid while idling" [Undecided,In progress] https://launchpad.net/bugs/574910 | 19:31 |
| jiboumans | action smoser to just fix it? ;) | 19:31 |
| jjohansen | smoser: I will make some time to look at it again tomorrow | 19:32 |
| smoser | we really, really, really dont want people using our images to stay on karmic or hardy. | 19:32 |
| jjohansen | the kt is doing a bug day, and its on my list | 19:32 |
| smoser | jjohansen, 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 |
| SpamapS | jiboumans: chiming. :) | 19:32 |
| smoser | anyone have anything else for jjohansen ? | 19:32 |
| jiboumans | jjohansen: smells of io | 19:33 |
| jiboumans | jjohansen++ # kernel hackery | 19:33 |
| * jjohansen needs a shower | 19:33 | |
| smoser | [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer) | 19:33 |
| MootBot | New Topic: Weekly Updates & Questions for the Documentation Team (sommer) | 19:33 |
| sommer | don't have anything new this week, but should have some updates for next week | 19:33 |
| sommer | anyone else have questions comments for me? | 19:34 |
| jiboumans | sommer: maybe out of your scope, but i get questions about cloud-init / cloud-config regularly | 19:35 |
| jiboumans | are we covering this in our docs as well? | 19:35 |
| * smoser ducks | 19:35 | |
| sommer | jiboumans: not too sure, but I can definitely check on that for next week | 19:35 |
| jiboumans | it'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 doc | 19:35 |
| MootBot | ACTION received: sommer to check on getting some cloud-init / cloud-config doc | 19:35 |
| jiboumans | sommer: that'd be great. they're amazing tools but not everyone's discoverd them yet | 19:36 |
| sommer | cool, I'll focus on updating that section | 19:36 |
| jiboumans | sommer++ thanks | 19:36 |
| smoser | [TOPIC] Weekly SRU review (zul) | 19:36 |
| MootBot | New Topic: Weekly SRU review (zul) | 19:36 |
| jiboumans | ttx, can you take that? | 19:36 |
| jiboumans | zul's at a conference today and i dont think he managed to join in | 19:36 |
| === Andre_Gondim is now known as Andre_Gondim-afk | ||
| zul | actually im here briefly | 19:38 |
| jiboumans | awesome | 19:38 |
| jiboumans | zul: then, if you don't mind | 19:38 |
| zul | we have recieved 2 requests this week | 19:38 |
| zul | the list went out on monday both are virt related i dnot have the bug numbers in front of me though | 19:39 |
| zul | so they will be looked at on friday and be added to the list for next week | 19:39 |
| hallyn | bug #579584 | 19:39 |
| ubottu | Launchpad bug 579584 in libvirt (Ubuntu) "setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu" [Medium,Fix released] https://launchpad.net/bugs/579584 | 19:39 |
| zul | thats one of them ;) | 19:40 |
| smoser | i nominated bug 598649 . | 19:40 |
| ubottu | Launchpad bug 598649 in qemu-kvm (Ubuntu) "cannot boot grub multiboot image with kvm -kernel" [Medium,Fix released] https://launchpad.net/bugs/598649 | 19:40 |
| smoser | it 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 |
| hallyn | smoser: hm, the problem with that one is we'd have to do pretty big updates for kvm+seabios for lucid | 19:40 |
| smoser | hallyn, yeah. i expected that as a possibility. | 19:41 |
| hallyn | i.e. we'd have to update to qemu 12.4 | 19:41 |
| jiboumans | the other is bug #603363 | 19:41 |
| ubottu | Launchpad bug 603363 in openssh (Ubuntu) "sshd never stops, prevents umount of /usr partition" [Medium,Fix released] https://launchpad.net/bugs/603363 | 19:41 |
| zul | unfortunately the wireless here is sucking | 19:41 |
| zul | so thats it for me | 19:42 |
| smoser | [TOPIC] Rubygems in Ubuntu (SpamapS) | 19:42 |
| MootBot | New Topic: Rubygems in Ubuntu (SpamapS) | 19:42 |
| SpamapS | Right | 19:42 |
| SpamapS | Its unfortunate that Mathiaz isn't here so he can comment on the past, but I'll share the current | 19:43 |
| SpamapS | everybody who uses ruby, uses rubygems.. and it is horribly broken for most people in Debian and ubuntu | 19:43 |
| SpamapS | the main gripe is that it stores binaries that would normally be placed in /usr/bin or (by configuration) /usr/local/bin, in /var/lib/rubygems | 19:44 |
| SpamapS | s/binaries/executables/ | 19:44 |
| SpamapS | So 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 |
| SpamapS | mathiaz tried to "fix" this 2 years ago but had his upload reverted. | 19:45 |
| smoser | so do we want to add this to next weeks agenda with Mathiaz here and leave this as a teaser ? | 19:46 |
| SpamapS | Any 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/lib | 19:46 |
| zul | i dont think anything should be placed in /usr/local/bin | 19:46 |
| zul | sorry laggy | 19:46 |
| SpamapS | I'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 |
| SpamapS | zul: we allow CPAN to do that. | 19:47 |
| SpamapS | and every autoconf script out there puts things in /usr/local | 19:47 |
| smoser | SpamapS, by default cpan on ubuntu/debian puts things in /usr/local ? | 19:47 |
| SpamapS | smoser: 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 |
| SpamapS | which does /usr/bin | 19:48 |
| SpamapS | But it remains an important issue | 19:49 |
| smoser | usr/bin just seems dirty. | 19:49 |
| jiboumans | cpan on debian didn't used to be well behaved | 19:49 |
| jiboumans | let me check | 19:49 |
| SpamapS | users want these executables in their path | 19:49 |
| * ttx is kinda back | 19:49 | |
| ttx | at ~40% packet loss | 19:49 |
| jiboumans | yeah, i think cpan is still naughty | 19:49 |
| SpamapS | it breaks things mightily for the executables to be in /var/lib (which some might argue, can be mounted noexec) | 19:49 |
| smoser | so what do we want to do here ? | 19:50 |
| jiboumans | $ perl -MConfig -le'print $Config{installbin}' | 19:50 |
| jiboumans | /usr/bin | 19:50 |
| SpamapS | jiboumans: doh | 19:50 |
| SpamapS | smoser: we want to make sure users can use the software the way they want to. | 19:51 |
| jiboumans | spamaps: this is what local::lib and INSTALLDIRS=site is for, but it's not the default | 19:51 |
| SpamapS | smoser: without encouraging stupidity. ;) | 19:51 |
| SpamapS | right now, *everybody* reinstalls rubygems from source | 19:51 |
| smoser | well, i meant regarding this discussion. | 19:51 |
| SpamapS | the options we came up with were: | 19:51 |
| SpamapS | a) switch to using the embedded rubygems from ruby 1.9 | 19:52 |
| ttx | SpamapS: if you haven't had this discussion with mathiaz, you should | 19:52 |
| ttx | SpamapS: he got burnt in those waters already | 19:52 |
| SpamapS | b) attempt to re-do the change mathiaz did, after discussion with motu council | 19:52 |
| SpamapS | c) 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 |
| SpamapS | ttx: mathiaz and I discussed it at length with several ruby users and authors including the Chef guys. | 19:53 |
| ttx | SpamapS: ok, I was missing some context, I see | 19:53 |
| SpamapS | ttx: Jos also had some other discussions on the same vein. | 19:54 |
| zul | `maybe send an email to -devel and -serve to get more feedback | 19:54 |
| SpamapS | Either way, it was by far the most common complaint I got about Ubuntu Server at velocity. | 19:54 |
| jiboumans | agreed | 19:54 |
| jiboumans | it's a recurring theme for me | 19:54 |
| jiboumans | i'm open to any route forward, just not one that leaves an essential package in a state that the its users can't actually use | 19:55 |
| ttx | SpamapS: it's good for me to see it's no longer about how much our Tomcat sucks | 19:55 |
| SpamapS | ttx: :-D | 19:55 |
| jiboumans | ttx++ # fixing tomcat ;) | 19:55 |
| smoser | mdz 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 |
| smoser | are we ready to move on ? | 19:56 |
| smoser | we're back to zul | 19:56 |
| smoser | [TOPIC] Apport hooks call for participation (zulcss) | 19:56 |
| MootBot | New Topic: Apport hooks call for participation (zulcss) | 19:56 |
| jiboumans | hang on | 19:56 |
| SpamapS | Lets 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 |
| jiboumans | what action are we taking SpamapS? | 19:56 |
| smoser | sorry. | 19:56 |
| SpamapS | ^^ | 19:56 |
| SpamapS | should I contact jcastro? | 19:57 |
| jiboumans | spamaps: adam and james will also be able to point you at relevant communities | 19:57 |
| jiboumans | and yes, contact jcastro | 19:57 |
| jiboumans | spamaps: is there anything that would be required to be resolved before feature freeze for it to make maverick? | 19:57 |
| jiboumans | or is maverick too optimistic? | 19:58 |
| SpamapS | jiboumans: not sure. | 19:58 |
| SpamapS | if you ask me, the package is 100% broken and this is SRU worthy given users complete abandonment of the package. | 19:58 |
| jiboumans | SpamapS: think about the options in that context too.. i'd love to see something workable already in maverick | 19:59 |
| smoser | well, nothing is SRU worthy unless fixed in development release. | 19:59 |
| jiboumans | SpamapS: can you get the discussion rolling and update us next week in prague? | 20:00 |
| jiboumans | we'll then revisit here in the next irc meeting | 20:00 |
| SpamapS | Yes 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 ubuntu | 20:01 |
| jiboumans | smoser, action spamaps please? | 20:01 |
| MootBot | ACTION received: SpamapS to send mail to -devel to get ruby community position on ruby gems in ubuntu | 20:01 |
| jiboumans | thanks :) | 20:01 |
| smoser | now moving on ? | 20:01 |
| === zyga is now known as zyga_ | ||
| jiboumans | yes please | 20:01 |
| smoser | [TOPIC] Apport hooks call for participation (zulcss) | 20:01 |
| MootBot | New Topic: Apport hooks call for participation (zulcss) | 20:01 |
| smoser | zul, | 20:01 |
| jiboumans | i'll take that one | 20:02 |
| jiboumans | zul's connection is flaky | 20:02 |
| jiboumans | so, as i mentioned above, our commitment for Alpha3 is quite high | 20:02 |
| jiboumans | and that means we're not likely to get many new apport hooks this cycle | 20:02 |
| jiboumans | and that'd be a real shame. | 20:03 |
| jiboumans | as 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 contributions | 20:03 |
| jiboumans | I highlighted this in the Alpha3 update here: https://lists.ubuntu.com/archives/ubuntu-server/2010-July/004411.html | 20:03 |
| jiboumans | and zul will be sending out something specific to apport hooks in the next day or two | 20:04 |
| jiboumans | if you have some spare cycles and have a package you care about with apport hooks, please consider contributing one! | 20:04 |
| jiboumans | I hope i represented zul's thoughts well there | 20:04 |
| jiboumans | smoser: that's it from me | 20:04 |
| smoser | [TOPIC] Open Discussion | 20:04 |
| MootBot | New Topic: Open Discussion | 20:05 |
| smoser | i have one, just a re-announcement: | 20:05 |
| smoser | ec2 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 |
| ttx | smoser: what's HVM ? | 20:06 |
| smoser | (note, the $1408/hour is 880 * $1.6, which places 146 on Top 500) | 20:07 |
| ttx | Thanks everyone for assigning yourself to papercuts... don't forget to fix them before the end of the subcycle ! | 20:07 |
| smoser | HVM is hardware assisted virtualization. basically kvm but on xen. | 20:07 |
| smoser | its using the same infrastructure that windows instances previously used. (at least it seems to be) | 20:07 |
| smoser | ok. nothing else, then | 20:08 |
| smoser | [TOPIC] Announce next meeting date and time | 20:08 |
| MootBot | New Topic: Announce next meeting date and time | 20:08 |
| SpamapS | smoser: so is it something that is already on our radar to support, or did this come out of left field? | 20:08 |
| smoser | well, most everything comes out of left field for ec2. | 20:08 |
| SpamapS | :) | 20:08 |
| smoser | our relationship is improving, and i hope that results in better previews of this sort of thing. | 20:09 |
| smoser | the hvm is something htat i always expected they'd do. | 20:09 |
| smoser | but it is currently only available on the cluster compute isntance types. | 20:10 |
| smoser | anyway. | 20:10 |
| smoser | The meeting next week will be | 20:10 |
| smoser | Tuesday 2010-07-20 at 1800 UTC - #ubuntu-meeting | 20:10 |
| jiboumans | team, please join me on a phone call | 20:10 |
| jiboumans | thanks all! | 20:10 |
| ttx | jiboumans: that would be 8pm for most of us, next week | 20:10 |
| smoser | yeah, | 20:11 |
| smoser | was going to mention that. | 20:11 |
| jiboumans | ah, good catch | 20:11 |
| jiboumans | usually we skip the irc meeting during a sprint week | 20:11 |
| jiboumans | and i think it's advisable to do so this sprint too | 20:11 |
| ttx | yes | 20:11 |
| smoser | unless someone objects, then we'll resume our regularly scheduled program on | 20:11 |
| === MTeck is now known as MTecknology | ||
| smoser | Tuesday 2010-07-27 at 1800 UTC - #ubuntu-meeting | 20:11 |
| jiboumans | smoser++ # thanks for chairing | 20:11 |
| smoser | thank you, and good night. | 20:12 |
| smoser | #endmeeting | 20:13 |
| MootBot | Meeting 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 | ||
| czajkowski | #startmeeting | 22:57 |
| MootBot | Meeting started at 16:57. The chair is czajkowski. | 22:57 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 22:57 |
| czajkowski | #endmeeting | 22:57 |
| MootBot | Meeting finished at 16:57. | 22:57 |
| jpds | That was quick. | 22:57 |
| czajkowski | sorrya 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 | ||
| DiegoTc | xd | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!