=== jjohansen is now known as jj-afk === rsalveti` is now known as rsalveti === deegee_ is now known as deegee === Agent001 is now known as Agent007 === emma is now known as em === apachelogger is now known as releaselogger === yofel_ is now known as yofel === niemeyer is now known as niemeyer_lunch === releaselogger is now known as apachelogger === niemeyer_lunch is now known as niemeyer === niemeyer is now known as niemeyer_testing === niemeyer_testing is now known as niemeyer === bilalakhtar is now known as cdbs [16:01] hi [16:03] hi [16:03] hello [16:03] o/ [16:04] hi [16:04] you _can_ all hear me now right? :) [16:06] ohh, had we a mumble session? [16:06] #startmeeting [16:06] Meeting started at 10:06. The chair is robbiew. [16:06] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:06] jhunt_: yes ;) [16:06] doko: uh...every week ;) [16:07] [TOPIC] Lightning Round [16:07] New Topic: Lightning Round [16:07] psurbhi is on holiday [16:07] okay....who's up first.... [16:07] doko? [16:07] :) [16:08] spent most time on internal work, besides this: dso linker fixes, python 2.7.1 and 3.1.3 releases, openjdk-6 after-security-math, and some linaro work with hrw [16:08] -- [16:09] thnx [16:09] and thanks for all the "internal work" ;) [16:09] cjwatson? [16:10] done: fixed some issues with new grub2 snapshots; moved non-first kernels into a submenu; patch pilot day on Tuesday, hoovered up a reasonable amount of sponsorship reqs and old bugs; helping out with alpha-1 [16:10] todo: assemble initial blacklist for grub2-boot-framebuffer and package it somewhere (carried over) [16:11] er, patch-pilot day on *Monday* [16:11] -- [16:12] thnx [16:12] ev? [16:12] Trying to sort out this damned installer testing nonsense with IS, working on a ubiquity implementation of the automatic partitioning home preservation stuff (already done for d-i), had a meeting with ivanka and some agency people on one of her projects, working out a battle plan for testing more of the installer. [16:12] done [16:12] oh! I forgot about going down to London on Friday to talk with ev etc. about wubi [16:13] oh yeah [16:13] I did that too [16:13] ;) [16:13] installer nonsense? [16:13] testing the installer on a giant pile of netbooks hooked up to honeysuckle.millbank, driven by hudson [16:13] it works in principle [16:13] just needs some IS love [16:13] ahh [16:14] thnx ev! [16:14] mvo? [16:15] apt: merges; very first patch pilot; general merges; Msttcorefonts: uploaded to natty and maverick and improve failure condition for the EULA stuff; software-center: work on startup and long list display performance, setup daily builds; update-manager: bugfixes, add chroot mode that will skip kernel selecton, started on screen integration (server mode only); vmbuilder: tiny amount of work [16:15] startup-speed is doing nicely [16:15] list speed in a experimental branch is also shaping well [16:15] fingers crossed for a much speedier version soonish [16:15] (done) [16:16] mvo: cool...you ordered your test machine, right? [16:16] yeah, its here and the first set of tests is done [16:16] sweet [16:16] http://people.canonical.com/~mvo/software-center/mini10-startup/startup-times.png [16:16] LINK received: http://people.canonical.com/~mvo/software-center/mini10-startup/startup-times.png [16:17] its not very impressive currently though [16:17] still a nice dent already [16:17] mvo: what are you using to measure this? [16:17] ooooh...nice [16:17] *cough* [16:17] and do you have it documented anywhere [16:17] * robbiew suspects mvo has a stopwatch [16:17] while gtk.events_pending(): if window_main.flags() gtk.VISIBLE: break [16:17] lol [16:17] a precise one! [16:18] ev has a whole cupboard full of mini 10s :p [16:18] which I'm sure he's only using as bittorrent seeders [16:18] lol [16:18] pretty much [16:19] thnx mvo [16:19] barry? [16:19] I'm open for other ideas how to measure this, it seems to be working ok [16:19] python: soabi patch committed, issue closed; fixed problem w/--enable-shared. py27 ftbfs in natty: 662611 (virtualenv); 674175 (vte); 672209 (mutiprocessing); working on 683182 (graphviz). submitted bug+patch for cheetah and svn to debian & bug 605365 discussion. tomorrow: patch pilot. done. [16:19] Bug 605365 on http://launchpad.net/bugs/605365 is private [16:19] thanks for nothing ubottu [16:20] heh...thnx barry........heh...thnx barry [16:20] figured I'd keep the echo [16:20] :P [16:20] :-D [16:20] jhunt_: ? [16:20] Finished upstart bash-completion script and submitted for review on 25 Nov (http://article.gmane.org/gmane.comp.shells.bash.completion.devel/2695). No response from mailing list. Anyone have any thoughts on how long it should take them to respond? Is there are more direct route? After chatting to keybuk, spend day working out my weird mountall system hang. There are some potential tweaks we could make to upstart/mountall to avoid this problem occuring. [16:20] Process question: what should I do re the "affect dpkg" on lp:#674146 (Ubuntu natty-alpha-1 milestone)? It isn't actually a dpkg issue and I think this bug may be appearing on skaets list. None of the status options look appropriate so I guess I want to just remove the dpkg entry entirely? [16:21] bug 674146 [16:21] Launchpad bug 674146 in dpkg (Ubuntu Natty) "dpkg segfaults during debootstrap on natty armel" [High,Confirmed] https://launchpad.net/bugs/674146 [16:21] I tested a dpkg build with dokos patched gcc and it worked fine on kakadu. [16:22] it's not a dpkg issue though. [16:22] * doko already forgot about the toolchain updates :-/ [16:22] jhunt_: mark it invalid? [16:22] yeah [16:22] mark it invalid for the dpkg task [16:23] jhunt_: is dpkg rebuilt with default optimizations? [16:23] I guess. Should I update https://wiki.ubuntu.com/Bugs/Status though as it isn't clear that that status can be used for this scenario? [16:23] bash-completion> find one of the maintainers on IRC and chase them up that way? [16:23] probably best to just rebuild dpkg and close the bug when that's done [16:24] k. I was following their documented process, but... :) [16:24] jhunt_: if it's not a dpkg issue, then it falls under "This should also be used if the reported problem is not a bug at all, but for example user error " [16:24] dpkg does need to change, in a very technical sense of "be uploaded with no source changes" [16:24] ah [16:24] actually, there would be a source change to undo jhunt's workaround [16:25] it's more a "task" than a bug, but we don't have separate trackers for those really [16:25] so, then yeah. upload the change and fix committted [16:25] jhunt_: yeah...what barry said ;) [16:25] so forward a new patch to undo my last one to cjwatson ? [16:26] aye [16:26] thx [16:26] after alpha 1, though [16:26] k [16:26] EOT [16:26] jhunt_: thnx [16:26] Keybuk: ? [16:26] I'm afraid I don't think I've accomplished anything to report this week :-( [16:27] there was a techtalk ... rumors ... [16:27] heh..indeed [16:27] that was last week [16:27] http://blip.tv/file/4444396 [16:27] LINK received: http://blip.tv/file/4444396 [16:27] \o/ [16:28] [TOPIC] Natty Stuff [16:28] New Topic: Natty Stuff [16:28] Alpha 1 tomorrow [16:28] ...hopefully :P [16:29] * robbiew hasn't been closely tracking feature work...but will start now [16:29] I'm planning to start a test rebuild tomorrow [16:29] still while the archive is frozen [16:30] doko: ok [16:30] barry: any plans to have work items for http://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-distributed-development-review-and-planning ? [16:30] robbiew: i really should get together w/james_w and figure that out ;) [16:31] i'll try to do that today [16:31] thnx [16:31] python2.7 as the default [16:32] we still have a little time to decide that [16:32] doko: any work items for http://blueprints.launchpad.net/ubuntu/+spec/foundations-n-dso-linking ? [16:32] barry: heh...but an early decision is ALWAYS preferred [16:32] ;) [16:32] robbiew: ok, I can add some ... [16:32] little time> for which, UDD or python2.7? [16:32] robbiew: no doubt :) [16:33] cjwatson: I believe python 2.7 [16:33] py27 [16:33] as default [16:33] doko: thnx [16:33] cjwatson: oh, we didn't tell you? we're making that change today. :) [16:33] jhunt_: would also be nice to get some work items in http://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-finish-upstart [16:33] my impression was that we had a decision to make 2.7 the default for natty [16:34] but I'm sure you and Keybuk will sort that ;) [16:34] barry: no complaints from this quarter [16:34] I'm just wondering when to do that switch [16:34] that's easy [16:34] [pitti] switch to systemd] [16:34] if we can get all main packages !ftbfs by feature freeze [16:34] barry: actually, one complaint. needs to be after alpha-1 [16:34] well, so make it the default after alpha1? [16:34] cjwatson: that's why the smiley [16:34] I wasn't sure :) [16:34] :) [16:35] is there any reason not to start on Friday, then? [16:35] cjwatson: sorry, you mean make py27 the default and deal w/ the fallout? [16:36] doko: AFAIK we decided to get 2.7 fully supported and then see where we were timewise. [16:36] robbiew: sure - I've collated everything discussed at UDS and subsequently and it's a pretty big list if we attempt to implement all of it. I need to discuss implementation details with Keybuk. [16:36] ScottK: when is this from your point of view? [16:36] yeah, that's kinda the problem, it's a huge list :p [16:37] jhunt_: ack...yeah, I imagine only a subset would be doable this cycle [16:37] my own attempts at writing are longer than yours [16:37] doko: From my POV if we get 2.7 fully supported prior to FF it should be default. [16:37] and then I suffer from feature paralysis [16:37] and FML etc. [16:37] ScottK: that was not my question [16:37] feature freeze is 24-feb, alpha-2 is 3-feb. i think *now* is not the time to switch, but let's make it a goal to switch at the rally [16:37] OK. What was your question? [16:38] ScottK: *when* to switch? [16:38] robbiew, Keybuk: do we need to try and prioritize the list maybe to see what gives biggest bang-for-buck? [16:38] that's sort of why in the upstart UDS session I was trying to encourage figuring out things that could be passed out to multiple people, cherry-picking things that can be noticeable improvements for 10.10, etc. [16:38] Not before we've done all the rebuilds and fixed FTBFS for sure. [16:38] 2.7 for 11.10 is too late. it's only a question *when* to switch for 11.04, not if [16:38] since I know that a giant list is hard to make progress on [16:39] jhunt_: dunno, it's one of those things where I'm worried that I'm going to end up spending the entire cycle just planning [16:39] jhunt_: well...I'd rather prioritize based on what's needed and also doable [16:39] doko: Then make the transition work get done smoothly and quickly and there will be nothing to argue about. [16:39] jhunt_: like...I think even the idea about examples in the man page would be a good thing to have [16:39] not that flashy, but very nice to have [16:40] ScottK: I'll make it as smoothly and quickly as the linking changes [16:40] That's what I'm afraid of. [16:40] I'd honestly rather we just smashed through it between alpha-1 and the rally (or even between alpha-1 and Christmas) [16:40] * robbiew is having dejavu...and recalls py2.6 by default [16:40] robbiew: I've almost completed 'init-examples' and it's coming along rather well I think. I'd rather have this info on the systems rather than (just) on the wiki to help out those in a disconnected environment. [16:40] rather than waiting until everything is perfect, and missing the deadline [16:41] +1 with cjwatson [16:41] I would not take this stance if it looked as though we might not have time [16:41] cjwatson: Are you on the python2.7 topic? [16:41] but does anyone not think that 2.5 months should be plenty? [16:41] ScottK: yes [16:41] in that case, I would like to make the test rebuild with 2.7 as the default, so we know immediately what needs to be fixed [16:41] doko: do it [16:41] I think that's a great idea. [16:42] cjwatson: i think 2.5 months should be plenty [16:42] then we should just get started on Friday, IMO [16:42] esp. if somebody sends a mail to -devel-announce with details of what needs to change in packages [16:43] cjwatson: well, in the ftbfs so far, there's no pattern [16:43] I can prepare something like this tomorrow [16:43] doko: You're going to rebuild everything, not just Main, right? [16:44] yes, but main gets priority [16:44] barry: ok, so no standard routine things? doko said he wanted us to get away from symlinks for at least packages on the CD at the same time [16:44] cjwatson: well, that's a bit controversial :) [16:44] for a smooth upgrade path in future [16:44] barry: oh? why? [16:44] isn't python2 the agreed future? [16:44] the controversy I know about is for packages sharing a namespace? [16:44] because it entails changing the build systems on packages before debian does [16:45] can't we work with Debian to do that in experimental? [16:45] and it does so w/o debian package maintainer input or approval [16:45] I didn't say it had to be without input or approval ... [16:45] cjwatson: It can. We just need to do the work with Debian part. [16:45] cjwatson: right, what ScottK says [16:45] right. I'm not saying we have to smash ahead with that with no forethought :) [16:45] but technically speaking, switching to dh_python2 is independent of making py27 the default [16:46] fair enough [16:46] I would prefer it this way. just imagine that there may be packages where this is not possible [16:46] we should do both, but we also need to prioritize [16:46] I think 2.7 as the default should be the priority. we could handle the robustness even after feature freeze [16:47] right. we're agreed that dh_python2 is the future and we should work with debian package maintainers to get that transition going. it's just not a blocker for py27 work [16:47] doko: +1 [16:48] doko: please do the test rebuild w/py27 as default. that will give us some excellent data [16:48] so we'll have a busy next week ... [16:48] better than boring :) [16:49] * mvo actually would like to have a boring day again - just one [16:49] :D [16:49] you'll have christmas [16:49] mvo: hey, you have the forced vacation coming up [16:50] ok...changing gears [16:50] got 10min left [16:50] [TOPIC] AOB? / Good News! [16:50] New Topic: AOB? / Good News! [16:51] natty still boots (ix86 only), not arm [16:51] python 3.2 beta 1 comes out on saturday [16:51] heh [16:51] mini10 s-c startup time measurements work - bad news is that its slow [16:51] the mini10 or s-c? :P [16:51] and unity/compiz work on my natty box (after a word or two with the right people) [16:51] which reminds me, doko: when b1 comes out, can we ditch py31 for natty? [16:51] robbiew: both! but the s-c part I hope to fix [16:53] okey dokey [16:53] #endmeeting [16:53] Meeting finished at 10:53. [16:54] thnx all [16:54] barry: I think it would be useful to support 3.1 and 3.2 both for Natty just to make sure we can do it. It's not on any CDs yet, to it really doesn't hurt. [16:54] thanks [16:55] ScottK: yeah, except all the good stuff (peps 3147 & 3149) is in 3.2 only [16:55] barry: no, no yet. and before making 3.2 the default I would like to wait for pep384 [16:55] doko: i think you mean 382 (namespace packages). i'm not optimistic that'll make it to 3.2 [16:56] 384 will *probably* make it. i've seen lots of commits from mvl [16:56] barry: no, I mean the abi pep [16:56] ah, cool. well, he has until saturday ;) === jj-afk is now known as jjohansen [17:01] robbiew: something tells me we're done [17:02] barry: [11:53:59] #endmeeting [17:02] heh [17:02] * ScottK thinks he knew already. [17:02] okay, thanks then! lunch awaits [19:00] good afternoon everybody [19:02] Just finishing testing the alpha candidate for i386 and amd64 [19:02] we only had one build that actually kind of worked recently (2010-11-30), but luckily we had that one and at least we'll have an alpha release this time round [19:11] I found some nice Edubuntu videos that someone made yesterday, added it as favourites to the channel: http://www.youtube.com/user/edubuntuproject [19:12] at current rate we'll also hit the 500 fans mark on facebook this week. we haven't really promoted it much besides having a button for it on our website, and it's grown quite well over the last 2 months since it was started [19:13] nice [19:14] Edubuntu council renewal is being dealt with by the CC, I was initially a bit worried that it might get stalled, but the CC is taking care of it. It's likely that the current EC will just be renewed, except for rich who stepped down [19:15] dinda: any updates from your side? [19:15] not really [19:15] holiday last week made it a short week [19:17] ah yes, forgot about that [19:18] stgraber, mgariepy: anything from you that you'd like to share this week or is that it? [19:18] not for me [19:19] I guess that's that then. If there's more then we can take it to #edubuntu [19:19] *gong* [21:00] hi folks, udd meeting about to start [21:00] #startmeeting [21:00] Meeting started at 15:00. The chair is barry. [21:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [21:01] [TOPIC] agenda [21:01] New Topic: agenda [21:01] https://wiki.ubuntu.com/DistributedDevelopment/20101201 [21:01] (hi all) [21:01] [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20101201 [21:01] LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20101201 [21:01] poolie: hi [21:01] i guess we'll wait a few minutes for folks to show up [21:02] * jelmer waves [21:02] * ajmitch_ is sort of caught up in stuff at work this morning [21:03] ajmitch_: cool. thumper, james_w hi [21:03] hey [21:03] no slangasek? [21:04] let's get started then... [21:04] [TOPIC] action items [21:04] New Topic: action items [21:04] reviewing from 2 weeks ago [21:04] slangasek is on vacation [21:04] james_w: ack [21:05] * barry to start some sphinx docs to be well-integrated w/ wiki.u.c (ongoing) [21:05] [21:05] we've been in discussion w/ dholbach and others about this re: updating the packaging guidelines. i think the above action will fall under that initiative so i'm going to mark this one as done [21:05] or at least take it off the list :) [21:06] * poolie to capture uds session notes in a wiki page, with more detail (turn it into a blueprint?) [21:06] [21:06] k [21:06] i didn't write anything more detailed about the uds sessions [21:06] i did linke to the transcript [21:06] and post about the survey results, after which there was some discussion [21:07] is more summary documentation of UDS wanted? [21:07] i don't think it's a high priority now [21:08] agreed. the only thing left is to decide whether we want to add some work items to the blueprint [21:08] poolie: didn't you already send a brief summary to the list? [21:08] jelmer: hi! [21:08] hey Barry :-) [21:08] i can't recall if i did that before or after the previous meeting [21:08] so it's either done, or scratched off :) === JanC_ is now known as JanC [21:09] Now, which meeting is this? [21:09] cdbs: Ubuntu Distributed Development [21:09] the blueprint is here: https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-distributed-development-review-and-planning [21:09] poolie: k [21:09] * cdbs is a fan of UDD, so will watch around [21:10] next? ajmitch? [21:10] * ajmitch to come up with questions/topics for next meeting (re: REVU) [21:10] [21:11] ajmitch_: we can carry that one forward to the next meeting if you want [21:12] i guess we will [21:12] * poolie to send bzr rotation pitch to platform mailing list [21:12] [21:12] still to do; carry it over [21:13] thx [21:13] that's it for action items [21:13] [TOPIC] work items for blueprint [21:13] New Topic: work items for blueprint [21:13] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-distributed-development-review-and-planning [21:13] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-distributed-development-review-and-planning [21:14] so we have this blueprint, and robbiew was pinging me about work items for natty. i'm being kept pretty busy this cycle and sadly haven't had much time to circle back to udd work. what can we realistically accomplish this cycle that we want to add to the blueprint? [21:14] i'm not quite sure what that means [21:14] barry: apologies, in the middle of debugging something - next meeting would be good [21:14] these are work items so that we can track how much effort we should/have expend? [21:15] or how much progress was made? [21:15] i think robbiew is looking for work items that we can still accomplish in natty cycle [21:15] right, so tracking effort yet to be expended [21:15] so after the survey and uds, there are two main things i want to do in the bzr team [21:15] - get network performance closer to apt-get source [21:16] (we should set a quanitifiable target, but i think we should do more investigation first) [21:16] - get the imports working more reliably [21:16] those seem like things that would help and that are plausible for natty [21:17] perhaps they're too big/small/vague to be work items? [21:17] wholehearted +1 for both [21:17] probably to big/vague, though great goals [21:18] well, network performance closer to apt-get source seems nearly work item-y [21:18] maybe with some percentage for "close"? [21:19] i think to make it specific and measurable we need to describe things more specifically [21:19] poolie: is there a specific way of fetching you have in mind to compete with apt-get source ? Is this for 'bzr co --lightweight' / 'bzr branch' / whatever is fastest ? [21:19] for, someone with GbE to a source mirror there is no prospect we'll match it in the short term [21:19] jelmer, first looking for waste in simple branching atm [21:20] or an a lightweight checkout [21:20] next, a shallow checkout - john is doing code changes towards that [21:21] poolie: wasn't there some talk about trying to set up local mirrors of branches? would that be more than just a fancy cron? [21:22] it wouldn't necessarily have to be more than that [21:22] my inclination is to try to make the straightforward use faster first [21:23] perhaps we should look at doing it earlier? [21:23] it could be a big win but it also makes things a little more complicated [21:24] it's hard for me to say. bzr branch is not onerous for me, so it wouldn't be a huge win for me. but for others it might be [21:24] let's leave that as a medium priority [21:24] i think there's a bug in udd discussing it [21:24] we can still add it as a work item though [21:25] i think what you describe above could be condensed into other work items, at least for now (they can always change later). i can take a shot at extracting that if you want [21:26] and poolie you can decide later about resource allocation [21:29] can you point me to a spec that is a good example of the right work item granularity? [21:29] i'm not sure such a thing exists ;) [21:29] but hang on, let me see if i can find something close [21:29] https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-robust-python-packaging [21:29] that one has gone through a few iterations, but sadly blueprint whiteboards have a history erase button [21:29] or no history at all, in fact? [21:29] indeed [21:29] ok i see [21:29] so this might help us keep track of things that don't match well to single bugs, or that aren't all in the same pkg [21:29] yep [21:29] i'll see about adding them as we go along [21:29] on the package importer failures, iiuc, we have very close to 2k failures, with some common problems. perhaps a few work items there could be: categorize failures; make sure bugs are filed; fix top two common failures; reduce failures by 50%, etc. [21:30] poolie cool. i'll leave that to you [21:30] at the moment we have something at a similar level on https://wiki.canonical.com/Bazaar/Plate [21:32] we also have a work item for moving that infrastructure into IS, right james_w? [21:32] right [21:32] that progressed a bit, i think [21:32] yes [21:32] it's mostly gated on IS having time (in between midnight outages) to rebuild a machine for us [21:32] cool. should definitely add it as a work item to get credit for it :) [21:32] what do you think about the other suggestions above? [21:33] i think those would be good steps === bilalakhtar_ is now known as cdbs [21:33] an item of getting it to zero might be elusive but we could have incremental steps [21:34] yep. i'll add those, and of course they can always be changed [21:34] any other thoughts on the blueprint work items? [21:35] guess that's a no? [21:36] [TOPIC] bugs of interest [21:36] New Topic: bugs of interest [21:36] should the list be roughly the length of things we expect to do before natty? or conservative, or optimistic? [21:36] for now it can be optimistic. it's very easy to postpone, remove, change items as the cycle progresses, with really no penalty to do so [21:36] because we did this in detail last week, i propose this week just to talk about ones that changed or are interesting [21:37] k [21:37] poolie: +1 [21:37] https://bugs.launchpad.net/udd/+bug/653307 is, i think, understood, but needs to be finished [21:37] Ubuntu bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys" [Critical,In progress] [21:37] https://bugs.launchpad.net/bzr/+bug/603395 is fixed or nearly fixed? [21:37] Ubuntu bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] [21:38] james_w: are you here? any comments on redoing the imports affected by 653307? [21:38] I am [21:38] * ajmitch hopes that the logging bot didn't get disconnected as well [21:38] https://bugs.launchpad.net/bzr/+bug/556132 is being worked on by exarkun, a twisted developer [21:38] Ubuntu bug 556132 in Launchpad Bazaar Integration "bzr: ERROR: paramiko.SSHException: Key-exchange timed out; consistent after sending 1GB data" [Medium,Triaged] [21:39] and i think that's all that's changed from that list this week [21:39] poolie, was my comment in the bug unclear? [21:39] no, perfectly clear, thanks [21:39]