=== poolie_ is now known as poolie === emma is now known as em === Igorot is now known as Knightlust === dholbach_ is now known as dholbach === Chipaca` is now known as Chipaca [15:00] #startmeeting [15:00] Meeting started at 10:00. The chair is NCommander. [15:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:00] o/ [15:00] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110714#preview [15:00] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110714#preview [15:00] who's here? [15:01] * GrueMaster apparates into the area. [15:01] [topic] Standing Items [15:01] New Topic: Standing Items [15:02] [topic] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html [15:02] hi [15:02] New Topic: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html [15:03] [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-2.html [15:03] LINK received: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-2.html [15:03] hrm [15:03] * GrueMaster notes that we are now in alpha 3. [15:03] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-3.html [15:03] LINK received: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-3.html [15:04] we're off treadline [15:05] GrueMaster: do you need help with your workitems? [15:06] * NCommander echos [15:06] I should be able to get them started next week, now that I have systems with sata drives to throw into server testing. A lot of this can run in parallell. [15:06] k [15:06] [topic] ARM Server Status (NCommander, Daviey) [15:06] New Topic: ARM Server Status (NCommander, Daviey) [15:08] not much to add here, expect infinity's preinstall pool looks like it got impleeneted (I'm not sure the actual status; infinity ?) [15:09] I'm guessing he's not here, if he pops up we'll come back [15:09] Kernel Status (cooloney, ppisati) [15:09] [topic] Kernel Status (cooloney, ppisati) [15:09] New Topic: Kernel Status (cooloney, ppisati) [15:10] got a new drop from agreen today [15:10] that fixes a displauy problem we have [15:10] so far i've a 3.0.0-rc7 kernel running quite ok [15:10] there's still one issue with audio [15:10] or better, with pulse audio spamming the console (and thus consuming 100%cpu) [15:10] but the rest looks good to me [15:10] i've an ubuntu session running since a week [15:11] this was reklated to oneiric/ti-omap4 [15:11] i think i'll push it today or latest tomorrow [15:11] great! [15:11] on zinc, and i'll pubblish a kernel to test too [15:11] if only i could get rid of that audio problem... :P [15:12] anytihng have something to add or can I move on? [15:12] move [15:12] ARM Porting/FTBFS status (NCommander, janimo) [15:12] [topic] ARM Porting/FTBFS status (NCommander, janimo) [15:12] New Topic: ARM Porting/FTBFS status (NCommander, janimo) [15:12] fixed a few FTBFS these days [15:13] having a session on it today in Ubuntu Devel Week [15:13] w'eve had a toolchain bug which has broken quite a few packages like libkdraw [15:13] ocaml seems to be in a bad state, i think persia invested some time last night [15:13] has that gotten fixed? [15:13] I don't think it has [15:14] the register spilling issue [15:14] ugh [15:14] i dont see it on the ftbfs page though [15:15] are you sure it didnt build i.e. someone might have given it back [15:15] ogra_: it causes other packages to blow; gcc itself builds [15:15] i mean libdkraw [15:15] it may have gotten uploaded with the workaround set in its compile flags; I havne't checked all my email yet today [15:16] hmm and gcc-default failed to upload ... since may already [15:16] i wonder if doko_ just didnt notice or if thats on purpose [15:16] ghostscript is new on the list [15:16] antone else got something else? [15:17] ignore gcc-defaults [15:17] and cantor (no idea what that is) [15:17] doko_, thx [15:17] NCommander, move [15:17] [topic] ARM Image Status (ogra, NCommander) [15:17] New Topic: ARM Image Status (ogra, NCommander) [15:17] ah, libkdcraw seems to have beeen rebuilt successfully [15:17] would be nice if somebody could look at bug #810402 [15:17] Launchpad bug 810402 in ocaml (Ubuntu Oneiric) "all native ocaml programs segfault on armel" [High,Confirmed] https://launchpad.net/bugs/810402 [15:18] doko_, see above, persia is on it [15:18] infinity's preinstall pooled stuff was covered before [15:18] (with some community member) [15:18] I don't have anything else to ad [15:18] well [15:18] we don and wont have images for a while [15:18] debootstrap is completely hosed by the /run transition [15:18] ? [15:19] since quite a while already [15:19] bug number? [15:19] no idea if there is one [15:19] everyone is working on that though [15:19] since days [15:19] .......... if there is a critical bug with debootstrap there should be a bug [15:19] Any status on the imx5# images? [15:19] there surely is [15:19] :-P [15:19] i just dont know the number [15:20] GrueMaster, persias list points to first images for 20110801 [15:20] GrueMaster: without debootstrap its kinda moot ATM [15:20] ok [15:20] beyond that ScottK owns them [15:20] so ask him :) [15:21] Wanted to know as that will provide me with a current SATA system to do HD monitoring tests. [15:21] i dont think anything has happened on our side yet [15:21] can I ove on? [15:21] (will need debioan-cd integration etc) [15:21] ac100 kernel and flash-kernel support are uploaded to oneiric [15:22] kernel and meta are sitting in NEW, i chose to use .38 for the newer packages [15:22] NCommander, move :) [15:22] [topic] QA Status (GrueMaster) [15:22] New Topic: QA Status (GrueMaster) [15:23] Currently have an issue with two boards with overlapping mac addresses. [15:23] This will cause issues with automation testing & PXE boot. [15:23] ogra_, \o/ [15:24] GrueMaster: the MAC can be set in u-boot if need be [15:24] Rest of the systems now have sata<>usb drives attached and are currently running io tests. Should be done tomorrow. [15:24] try plugging the the cable backwards that probanbly changes the order of the MAC :) [15:24] NCommander: Not automated. [15:24] NCommander, there is already a u-boot patch to use the die-id [15:24] ogra_: reversing the polarity rarely works in real life [15:24] just not in yet [15:25] The die id is the same on two systems so that won't help. [15:25] The mac I am referring to is what the kernel is assigning based on die id. [15:25] ugh [15:25] same die-id ? thats evil [15:26] do you need them fixed ? [15:26] One is an EA1, the other is one of davidm's A1 boards. [15:26] else it could generate based on die-id and timestamp or so [15:26] so you at least have differing ones for each board [15:26] I have two more boards coming, and A3 and a fixed A1. A1 should be here early next week. No eta on A3. [15:27] hopefully with different IDs then :) [15:28] Work continues on automation using Jenkins. More ove a learning curve than anything. Current automated server tests are heavily interwoven with libvirt & kvm, so are all but useless to me. [15:28] great, so you can reimplement the world [15:29] Spent two days trying to get natty preinstalled netbook image (basis of filesystem testing) to run on btrfs failed. Based on the current status of that filesystem, I am not recommending it for default. [15:30] wow [15:30] did you file bugs ? [15:30] it should definitely at least *work* [15:30] Coudln't figure out what exactly was broken. [15:31] probably sluggish and all, but it should [15:31] did you do any ext4 testing yet ? [15:31] It was having mount issues in intramfs. [15:31] yes. Results were posted. [15:31] ah, great [15:31] Slightly faster than ext3. [15:31] where ? :) [15:31] They are in the blueprint. [15:32] well, ext4 has a bunch of flash optimization settings you can apply, there should be more differences if you flick all the switches [15:32] https://wiki.ubuntu.com/ARM/Specs/FasterPreinstallFilesystem [15:32] (i.e. the now well known TRIM support we banged our heads on durign the sprint) [15:32] ah, on the wiki [15:33] i looked at the spec [15:33] :) [15:33] anything else? [15:34] There is probably a way to combine the results into a single chart, but I haven't looked into it yet. [15:34] yeah, who cares [15:34] Nothing else to report on from here. [15:34] we only want the numbers for one shot anyway [15:34] [topic] AOB [15:34] New Topic: AOB [15:35] GIONG ONCE [15:35] TWICE [15:36] THREE TIMES [15:36] #endmeeting [15:36] Meeting finished at 10:36. === noy_ is now known as noy === noy_ is now known as noy [16:59] Hello [16:59] hi [17:00] #start-meeting [17:01] #startmeeting [17:01] Meeting started at 12:01. The chair is bdmurray. [17:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:01] Time for the Bug Squad meeting [17:01] the agenda is at: https://wiki.ubuntu.com/BugSquad/Meeting [17:02] [TOPIC] Updates of action items from previous meeting [17:02] New Topic: Updates of action items from previous meeting [17:02] vish to send an email to the lists re mentoring team admins [17:02] vish: Did this get done? [17:02] that was done IIRC [17:03] I seem to recall an email also [17:04] [Bugsquad-mentorship-group-alpha] Admin List in Bugsquad Mentoring team [17:04] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2011-June/003335.html <- that one ? [17:04] there we are [17:04] so that's done [17:04] yeah [17:04] hggdh: around? [17:04] hggdh to announce RedSingularity joining ubuntu-bugcontrol [17:05] that's been long enough that I think it should be dropped if its not done [17:05] we'll leave the other one pending [17:06] [TOPIC] Mentorship program discussion [17:06] New Topic: Mentorship program discussion [17:06] Is there anything to discuss here? [17:07] Moving on then [17:07] [TOPIC] New bug control members [17:07] New Topic: New bug control members [17:08] We've recently added the following two people to the Bug Control team [17:08] Daniel Manrique - roadmr [17:08] Brendan Donegan - brendand [17:08] Both of whom have been doing some great work and participating in Bug Days [17:08] Thanks for helping out! [17:09] just wanna say that they are both doing an amazing work, congrats guys :-) [17:09] [TOPIC] Open Discussions [17:09] New Topic: Open Discussions [17:09] o/ [17:10] charlie-tca: yes? [17:10] I forwarded a message that went to ubuntu developers about a response given on a bug. [17:10] The user requested the response be changed. Checking standard responses, he would like us to use that instead [17:11] Apparently, the triager used his own response, which is worded slightly off. [17:11] We need triagers using the standard responses, I think. [17:12] The response in question is [17:12] https://wiki.ubuntu.com/Bugs/Responses#Needing_testing_in_the_development_release [17:12] .. [17:12] charlie-tca: I'm fine with modifying the wording of the response - is that something you are willing to do? [17:12] I didn't see any need to change it [17:13] The response the user got was bad [17:13] where's this e-mail [17:14] ah, found it now.... [17:14] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2011-July/003374.html [17:14] charlie-tca: okay I'm with you now [17:15] If the standard had been used, I think it would not have been questioned [17:15] Do we know who used the response in question? I ask because the writer says "The n-th time" [17:15] I don't know [17:15] no bug number was given [17:16] okay I'll find out [17:16] [ACTION] bdmurray to find out who wrote comment in https://lists.ubuntu.com/archives/ubuntu-bugsquad/2011-July/003374.html [17:16] ACTION received: bdmurray to find out who wrote comment in https://lists.ubuntu.com/archives/ubuntu-bugsquad/2011-July/003374.html [17:17] and if the person really is saying that a lot I'll contact them [17:17] bdmurray: see bug 688586 [17:17] Launchpad bug 688586 in empathy (Ubuntu) "Empathy doesn't work well after update; user should be warned" [Low,Incomplete] https://launchpad.net/bugs/688586 [17:17] well I guess my action is done! [17:18] oh was it me? [17:18] I wasn't gonna say that but since you did ... [17:18] guess i should update the comment in the script then [17:18] first comment i got about it though [17:19] but one is enough [17:19] well... I agree [17:19] pedro_: if its a script you might consider look at the number of comments in addition to the status [17:20] pedro_: that's bug.message_count in the api [17:20] bdmurray, i look at all that [17:20] number of comments, status, date last changed etc [17:20] okay cool [17:21] well, the reporter was the last one to comment in this case, so that type of response isn't warranted [17:22] micahg: that may not the best way to check since any apport bug has the first comment from the reporter [17:22] comment_count > 1, last_commenter=reporter (not real API usage) [17:23] okay lets let pedro write his own code [17:23] don't need any backseat coders! [17:23] Is there any other business? [17:23] wasn't suggesting code...but rather a possible algorithm [17:23] o/ [17:24] micahg: okay as long as its not about algorithms [17:24] heh [17:25] about a year ago we discussed about not giving stock replies to users when all the reproduce steps are there, this seems to be happenning now with some of these automated scripts [17:26] this seems to include bugs already in the triaged state [17:26] ah this is leading into algorithm to detect bug descriptions with steps to reproduce? [17:26] no [17:26] darn! [17:26] just wanted to bring it up :) [17:27] could be those updated with the 'TEST CASE' thing as the SRU's ? [17:27] I honestly don't know how to test for steps to reproduce in the bug description [17:27] although, if there were a keyword in the description, we could check for that on newer bugs [17:27] However if they were Triaged then modifying the description to add TEST CASE as pedro suggests makes sense [17:28] Additionally, tagging 'testcase' would be much easier to search on [17:28] yup [17:28] hm, actually, https://wiki.ubuntu.com/Bugs/Description does say use TEST CASE [17:29] so what actions can we take / make out of this [17:30] don't auto incomplete triaged bugs via a script [17:30] i'd like the idea of having the tag too [17:30] tag bugs with 'TEST CASE' in description testcase [17:30] recommend people modify description with 'TEST CASE' words if steps to reproduce exist in bug description [17:30] start moving steps to reproduce to description as "test case"? [17:31] caps, please, micahg [17:31] yeah if they are in comment like #28 out of 100 [17:31] heh you don't hear that very OFTEN! [17:32] caps makes it easier to see in the descriptions [17:32] charlie-tca: OK, I WILL TRY TO REMEMBER :) [17:32] oh, man! [17:32] lol [17:32] are we agreed on the actions then? [17:32] * micahg does use caps in the descriptions though :) [17:32] +1 [17:33] +1 [17:33] +1 [17:33] [ACTION] bdmurray tag bugs with 'TEST CASE' in description testcase [17:33] ACTION received: bdmurray tag bugs with 'TEST CASE' in description testcase [17:34] I would think the only exceptions might be kernel/X since hardware might not be available [17:34] [ACTION] bdmurray recommend people modify description with 'TEST CASE' words if steps to reproduce exist in bug description or in comments [17:34] ACTION received: bdmurray recommend people modify description with 'TEST CASE' words if steps to reproduce exist in bug description or in comments [17:34] If the steps are there to reproduce, it doesn't matter if you have the hardware, does it? [17:34] charlie-tca: for kernel/X it can [17:34] it is still a TEST CASE, though? [17:35] It doesn matter but its still worth noting there is a TEST CASE [17:35] if the bug is hardware specific [17:35] right, I was referring to the triaged part [17:35] ah well the kernel's special [17:35] oh, kernel team is different on that [17:36] okay any other business? [17:36] o/ [17:36] bdmurray: you forgot one of the actions from your list :) [17:37] I recently wrote an update-manager apport package hook - this is now in natty-proposed and could use some SRU verification [17:37] that is bug 797894 [17:37] Launchpad bug 797894 in update-manager (Ubuntu) "update-manager bug reports would benefit from an apport-hook" [Undecided,New] https://launchpad.net/bugs/797894 [17:37] micahg: which action is that? [17:37] don't auto incomplete triaged bugs via a script [17:38] micahg: I won't and don't - should I email others not to either? [17:38] maybe? [17:39] bdmurray: you proposed it as a possible action, was wondering what you had in mind [17:39] yes so was I [17:39] Heh [17:41] maybe just a reminder about the triaged state and why bug reports end up there and that people should keep that in mind when writing these scripts? [17:41] [ACTION] bdmurray to recommend that auto bug modifiers not incomplete bug reports that have been triaged as triaged is a state settable only by people who know [17:41] ACTION received: bdmurray to recommend that auto bug modifiers not incomplete bug reports that have been triaged as triaged is a state settable only by people who know [17:41] that sounds reasonably close to what micah said [17:41] so any other business? [17:44] okay thanks everyone! [17:44] #end-meeting [17:44] bdmurray: Thank you for chairing these meetings! [17:44] bdmurray: no dash [17:45] #endmeeting [17:45] Meeting finished at 12:45. [17:45] thanks bdmurray [17:45] thanks! [17:58] heya, i'll be a few minutes late... [17:59] I have to say I don't actually remember what's left on the agenda [18:00] we handled a good deal of https://wiki.ubuntu.com/TechnicalBoardAgenda at the rally [18:00] I've missed the past two and have no idea what's going on [18:00] I believe that the question of MRE for banshee is still open, but I think we were going to follow up on the mailing list for that [18:00] I therefore un-volunteer to chair [18:00] the series RM bit I was going to take care of, though haven't yet [18:01] how about I start and we can move through the things I know about, and anyone with more of a clue about what's going on can chip in [18:01] #startmeeting [18:01] Meeting started at 13:01. The chair is cjwatson. [18:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:02] [TOPIC] Action review [18:02] New Topic: Action review [18:02] cjwatson to set series RM to ubuntu-release [18:02] not done [18:02] the banshee MRE is done, fyi: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [18:02] everyone to follow up to mailing list threads [18:02] no ideda [18:02] Laney: oh good, thanks [18:02] (er, one moment, need to attend to my daughter) [18:03] we have the DMB voting procedure question still outstanding, I think, but that really does need to be handled by e-mail [18:04] [TOPIC] Patent enquiry - mesa floating point buffer support (RAOF) [18:04] New Topic: Patent enquiry - mesa floating point buffer support (RAOF) [18:04] https://lists.ubuntu.com/archives/technical-board/2011-July/000961.html [18:04] I'm very behind on Ubuntu email right now, I'm afraid [18:04] mdz: understandable :) [18:05] I was under the impression that our standing policy was only to take action when notified of patent infringement by a patent holder [18:05] however, given the form of the question, I think we need somebody who can assume risk on behalf of Canonical to answer [18:05] I think we err on the side of making the software better [18:05] does anyone object if I forward the question to legal and/or Mark? or should we tell RAOF to go ahead? [18:05] and patent claims can push back iff there is a genuine problem [18:06] cjwatson, I think according to https://wiki.ubuntu.com/PatentPolicy RAOF should go ahead [18:07] RAOF seems to be following the last section of that [18:07] * kees agrees [18:07] but I guess the answer is "we are not aware of any active claims here" [18:08] precisely [18:08] and we seem to have a plausible defence anyway in the form of RAOF's belief that the patent involves a hardware circuit [18:09] yes [18:09] so that's agreed, I'll reply to Chris' mail in the course of preparing minutes for this meeting [18:09] there is no claim as far as we're aware, and our best guess at a read of the patent says we can't possibly infringe [18:09] [ACTION] Brainstorm Top 10 for June 2010 [18:09] ACTION received: Brainstorm Top 10 for June 2010 [18:09] https://lists.ubuntu.com/archives/technical-board/2011-July/000962.html [18:10] mdz: https://lists.ubuntu.com/archives/technical-board/2011-July/000968.html is directed at you [18:10] bah! [18:10] [TOPIC] Brainstorm Top 10 for June 2010 [18:10] New Topic: Brainstorm Top 10 for June 2010 [18:10] sorry, brain failure [18:10] 2011? :-) [18:10] further brain failure, but this time on the part of the enquirer ... I was just copying and pasting :-) [18:11] so I did the first one, and pitti did the second one [18:11] sounds like it's not your turn then [18:11] kees: should we flip a coin? [18:11] I'd appreciate if we could rotate, yes :-) [18:11] between me and pitti, there's a pretty well established formula [18:11] yeah [18:12] I'm happy to do it and get it out of the way for a while [18:13] cjwatson, thank you [18:13] [ACTION] cjwatson to initiate brainstorm review [18:13] ACTION received: cjwatson to initiate brainstorm review [18:13] cjwatson: cool; I'll take the next one [18:13] [TOPIC] AOB [18:13] New Topic: AOB [18:13] I don't see anything else in the mailing list or community bugs, aside from a few threads in progress [18:14] cjwatson, https://lists.ubuntu.com/archives/technical-board/2011-March/000726.html has all of the brainstorm review resources [18:14] at least, what existed when pitti started the last round [18:14] no other business from me [18:15] [TOPIC] chair for next meeting [18:15] New Topic: chair for next meeting [18:15] I have no idea whose turn it is. kees, can you take the next one maybe? [18:16] 28 July [18:16] yup! [18:16] sorry, woefully underprepared here [18:16] I'll be at OSCON, but hopefully will be able to attend [18:16] it's certainly my turn by now [18:16] I'll be at Debconf, but likewise [18:16] it's during Debconf too [18:16] I'll be around (not at debconf) [18:16] ok, thanks for chairing cjwatson [18:16] OK, let's call it a day then [18:16] mdz: hope the holiday's going well! [18:16] #endmeeting [18:16] Meeting finished at 13:16. [18:17] cjwatson, it's been grand. getting back to work Monday [18:17] ah, have fun [18:18] right. pub! :-) === aseem is now known as aseem|away === apachelogger_ is now known as apachelogger === Quintasan_ is now known as Quintasan === yofel_ is now known as yofel