[09:48] <lordievader> Good morning.
[10:50] <BluesKaj> 'Morning folks
[11:19] <elfy> good day peeps
[11:59] <leipzig> Hi all.
[11:59] <BluesKaj> hi elfy, leipzig
[12:01] <leipzig> Are there any plans to have Ubuntu 14.10 being capable of making an infrastructure hotspot out of the box?
[12:06] <leipzig> BluesKaj, Do you happen to know something about that? :\
[12:13] <BluesKaj> leipzig, dunno about 14.10, but this tut applies to 14.04, http://askubuntu.com/questions/453877/cannot-create-wifi-hotspot-in-ubuntu-14-04
[12:17] <leipzig> BluesKaj, Yes. ap-hotspot used to work properly in 13.10, but it depends on hostapd, which is broken in 14.04. Even downgrading it did not solve my problem for some reason.
[12:20] <BluesKaj> leipzig, perhaps the experts in #ubuntu-devel
[12:48] <Celine> Hello. Where should I give a sign to join Lubuntu 14.10 testing?
[12:49] <Celine> I've already installed Lubuntu 14.10, and don't want to test what has been tested.
[12:52] <BluesKaj> Celine, not sure, but you could ask in #ubuntu-devel
[12:53] <Celine> BluesKaj: Thank You.
[14:33] <aguitel> is mate avaleable in 14.10 ?
[14:33] <aguitel> how install mate desktop in 14.10?
[14:34] <lordievader> !info mate utopic
[14:35] <lordievader> !info mate-desktop-environment utopic
[14:36] <lordievader> aguitel: Doesn't seem to be available. Mind you I know nothing about Mate. It seems you can install Mate on Trusty, these instructions may work on Utopic too, but no promises made: http://www.enqlu.com/2014/03/how-to-install-mate-18-classic-desktop.html
[14:37] <aguitel> lordievader, thanks


[09:52] <oSoMoN> seb128, now that libvorbis's autopkgtests are fixed, can you please retry http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=libvorbis&trigger=glibc/2.31-0ubuntu10 , http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=libvorbis&trigger=glibc/2.31-0ubuntu10 , http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=libvorbis&trigger=glibc/2.31-0ubuntu10 , http://autopkgtest.ubuntu.com/
[09:52] <oSoMoN> request.cgi?release=groovy&arch=i386&package=libvorbis&trigger=glibc/2.31-0ubuntu10 and http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=libvorbis&trigger=glibc/2.31-0ubuntu10 ?
[11:46] <seb128> oSoMoN, done!
[12:06] <ahasenack> good morning
[12:06] <ahasenack> rbalint: oSoMoN: morning, fellow +1maintainers
[12:06] <ahasenack> starting today's shift
[12:07] <ahasenack> my entries in the wiki page are up-to-date, I expect to land the 64bit aligntment fix of one of those golang packages, and follow up on the integer overflow on armhf on the other, and see if we can apply the golang-go (compiler) patch already to our golang 1.14 groovy package
[12:46] <oSoMoN> thanks seb128
[12:46] <oSoMoN> good morning ahasenack
[12:46] <ahasenack> hello oSoMoN
[12:59] <rbalint> ahasenack,o/
[12:59] <ahasenack> hi rbalint
[12:59] <rbalint> i'm proceeding with r stuff
[14:31] <ahasenack> rbalint: oSoMoN: I'm looking at yara and golang-golang-x-tools now (yara I'm almost sure the correct trigger will fix it, just tested with s390x)
[14:39] <teward> rbasak: can you let bryan who's working on the nginx merge know everything looks OK they just have to identify which bits have been included in Debian and alter the changelog for Ubuntu when they do the merge?  I think a lot of changes were incorporated in Debian now so the delta should be smaller now.  Some will still exist though
[14:45] <rbasak> bryce: ^
[14:48] <bryce> teward, yep I need to cleanup the changelog and verify autopkgtests but hoping to get through that today
[14:51] <teward> 👍
[14:51] <teward> awesome.  (Wasn't sure if you were the same bryce i worked with before
[14:51] <teward> UNRELATED phone autocorrect sucks ass.
[14:51] <teward> COmputers master race >.>
[14:52] <bryce> :-)
[14:52] <teward> rbasak: bryce: thanks again to the Canonical team helping with the merge
[14:52] <teward> FINALLY made a dent in the work for my job thanks to being *on site* again
[14:52] <teward> so starting to get back to 'normal' heh
[14:59] <bryce> teward, using git-ubuntu for splitting out all the history into individual commits helped a lot with organizing the delta.  There's a couple items I need to review where debian did things a tad bit differently than us.
[16:18] <oSoMoN> ahasenack, rbalint: FYI I'm looking at dh-python, I've identified one commit that fixes one failure (https://salsa.debian.org/python-team/tools/dh-python/-/commit/e289c25c861ae65ae9e7b52ebc09cf1f56061fa7), but there's another failure to address
[16:23] <ahasenack> fun
[16:23] <ahasenack> oSoMoN: I'm using the wiki page as my diary basically, striking out things that are done, and will use that content as my report later
[16:25] <oSoMoN> I tend to prefer offline notes :) but will update the wiki page with any ongoing items when I log off
[17:28] <oSoMoN> I attached a debdiff that fixes the dh-python autopkgtests to bug #1883297 (https://launchpadlibrarian.net/484997506/dh-python.debdiff), thanks in advance for reviewing/sponsoring
[17:31] <oSoMoN> the autopkgtest queues for arm* are almost empty, at long last \o/
[18:02] <oSoMoN> I asked yesterday but got no answer: could an AA please remove gmenuharness from groovy? it was removed in focal but somehow crept back in
[18:06] <teward> bryce: right, that's just because of the difference between Debian and Ubuntu.  But a large portion of the deltas (nginx-core being added, ss and iproute2 deps being added, etc.) can probably drop, we'll still have a few but it should be reduced substantially
[18:08] <bryce> ok
[18:47] <seb128> oSoMoN, I will do it for gmenuharness yes
[18:47] <oSoMoN> thanks
[20:32] <ahasenack> hi, can someone check if this dep8 job is stuck? http://autopkgtest.ubuntu.com/running#pkg-dropbear
[20:32] <ahasenack> the details show it's been running for just 7min, but since 2020-06-16
[20:33] <ahasenack> or am I reading that incorrectly, and that's when the job was requested
[22:33] <rbalint> please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/386127 for the r transition
[23:42] <xnox> doko:  i think i was one of the people who said "we will never need libc6-armel:armhf just drop it" well, here i am, using it.
[23:42] <xnox> so thank you for keeping it
[23:46] <sarnold> xnox: between that and my saucy hung task bug report, you sound like you're in a rough spot..


[01:00] <DreamWB> Hi
[01:00] <DreamWB> How can i be one of Membership ?
[01:00] <DreamWB> I've from thailand
[01:01] <DreamWB> and i'm not ensure to convert the timezome
[01:01] <DreamWB> of UTC into GMT
[01:01] <DreamWB> Oh sorry I've see the structions
[01:02] <DreamWB> Apologize for my less participate
[15:01]  * slangasek waves
[15:01] <infinity> o/
[15:01]  * stgraber waves
[15:02]  * ogra_ shores
[15:02] <cjwatson> ~~~___~~~
[15:03] <infinity> There seem to be some snakes on your plane.
[15:03] <cjwatson> there's a complex analysis joke in there somewhere
[15:03] <jodh> hi
[15:04] <slangasek> #startmeeting
[15:04] <meetingology> Meeting started Wed Mar 14 15:04:14 2012 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:04] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:04] <slangasek> [TOPIC] lightning round
[15:04] <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra infinity cjwatson)
[15:04] <slangasek> cjwatson ev stgraber barry ogra jodh doko slangasek infinity bdmurray
[15:06] <cjwatson> Release meeting:
[15:06] <cjwatson>  - Do a better job of writing hybrid MBRs on Intel Macs (bug 856826).
[15:06] <cjwatson>  - Reuse existing swap partitions and EFI System Partitions rather than creating new ones (bug 311299).
[15:06] <cjwatson>  - Arrange for Ubuntu Studio images to reconfigure jackd on boot (bug 923810).
[15:06] <cjwatson>  - Work on several EFI partitioning bugs (bug 769669, bug 811485).
[15:06] <cjwatson> Other:
[15:06] <cjwatson>  - Planning for installer sprint.
[15:06] <cjwatson>  - Some work on setting interview problems.
[15:06] <cjwatson>  - Various installer translation updates.
[15:06] <cjwatson>  - Multiarch fixes for pciutils (bug 948205) and libidl (bug 931388).
[15:06] <cjwatson>  - Improve debootstrap's handling of corrupted downloads (bug 954197).
[15:06] <cjwatson>  - Upgrade fixes for desktopcouch (bug 864328, bug 900570).
[15:06] <cjwatson>  - Currently trying to get my head around some more Mac partitioning bugs: bug 855871 and bug 856763.  Brain hurts, send cake.
[15:06] <cjwatson> ..
[15:06] <ev> - Ported the daisy code from Pika to amqplib, as that's what all other
[15:06] <ev>   Canonical services are using.
[15:06] <ev> - Build out a configuration for retracing machines.
[15:06] <ev> - Bug fixes in the WSGI applications (crash and core file acceptance).
[15:06] <ev> - Packaging oops-repository, python-pycassa, and python-thrift for IS (RT 48667)
[15:07] <ev> - Refactored whoopsie and broke out some separate utility code, adding tests
[15:07] <ev>   for all of it along the way.  This was in support of fixing how we determine
[15:07] <ev>   whether or not to submit a crash. Previously, we were only sending them on
[15:07] <ev>   the first instance. We now send it every time that crash occurs.
[15:07] <ev> - Did research and performance measurements around counting the contents of
[15:07] <ev>   crash buckets in Cassandra.
[15:07] <ev> - Finished initial bucketing code. There may be room for improvement around
[15:07] <ev>   how we're counting and recording bucket sizes, but some real idea from the
[15:07] <ev>   deployment will give me a much better indication.
[15:07] <ev> - Built a test harness around the WSGI applications (crash and core file
[15:07] <ev>   acceptance). Already quite a few serious fixes from this. Yay.
[15:07] <ev> - Started moving Cassandra-facing functionality into oops-repository, per my
[15:07] <ev>   discussion with Robert last week where he made the suggestion to use it
[15:07] <ev>   alone as the layer over the database.
[15:07] <ev> - Meeting with Amanda to discuss keeping her in the loop with respect to
[15:07] <ev>   changes to ubuntu-restricted-*
[15:07] <ev> (done)
[15:08] <stgraber> Bugs, bugs, bugs...
[15:08] <stgraber> - Networking
[15:08] <stgraber>  - RELEASE: Uploaded new isc-dhcp, converting to upstart and creating separate IPv4 and IPv6 jobs
[15:08] <stgraber>  - Investigated bug 919068 (bridge_ports all not working at boot time)
[15:08] <stgraber> - Installer
[15:08] <stgraber>  - RELEASE (generic): Bugfix work on ubiquity, casper and wubi
[15:08] <stgraber>  - Went through wubi merge proposals, merged a lot of bugfixes from bcbc
[15:08] <stgraber>  - Started going through the wubi bugs too
[15:08] <stgraber>  - Spent some time implementing bluetooth support in the installer
[15:08] <stgraber>  - Fixed the keyboard indicator
[15:08] <stgraber>  - Fixed a few bugs in casper related to persistent usb stick
[15:08] <stgraber>  - Various other ubiquity fixes and a few improvements to tests
[15:08] <stgraber> - Containers
[15:08] <stgraber>  - Worked/debugged apparmor and LXC with the security team, hoping to have an updated lxc today
[15:08] <stgraber> - TPM
[15:08] <stgraber>  - Started digging into opencryptoki, fixed bug 926305
[15:08] <stgraber> - Other
[15:08] <stgraber>  - RELEASE: Merged James' friendly-recovery branch adding support for LVM and APT status to the system-summary screen
[15:08] <stgraber>  - Had to deal with a security issue found in LTSP, fixing upstream and in Ubuntu + CVE and other paperwork
[15:08] <stgraber>  - Patch pilot on Monday
[15:08] <stgraber> - TODO this week
[15:08] <stgraber>  - Work on some ubiquity debugging wiki pages
[15:08] <stgraber>  - Continue working on bugs
[15:08] <stgraber> (DONE)
[15:09] <doko> heh, barry doesn't seem to be awake
[15:10] <doko> ogra: ^^^
[15:10] <ogra_> done:
[15:11] <ogra_> * not gotten to oem-config issues, will do so next week
[15:11] <ogra_> * trying to stopwatchg the initrd made me struggle on bug 936667 (--no-log helps)
[15:11] <ogra_> * did some more weeding through ubuntu-arm buglist (starts to look more sane)
[15:11] <ogra_> * missed my piloting on monday, will try to do before teh weekend
[15:11] <ogra_> * worked on Bug 948163 (fix in local branch, pending a push)
[15:11] <ogra_> * lots of community support issues (helped RTC issues with arm devices)
[15:11] <ogra_> * looked into a few ac100 installer bugs
[15:11] <ogra_> * booked my flight to UDS
[15:11] <ogra_> tod:
[15:11] <ogra_> * oem-config (this week for sure)
[15:11] <ogra_> * finish initrd timing
[15:11] <ogra_> * lookj into fsck delay on boot issue
[15:11] <ogra_> done
[15:11] <jodh> Off sick Monday. Been hit by bug 751689 this week which has hampered
[15:11] <jodh> efforts somewhat until I realized what was happening. Investigated
[15:11] <jodh> bug 940396. Initially thought it might be multi-arch related, but
[15:11] <jodh> seemingly its a subtle dependency bug: mvo has now recreated and
[15:11] <jodh> identified fixes. Worked on bug 508083 (currently testing). Writing some
[15:11] <jodh> new tests for Upstart as a precursor to syncing branches and updating
[15:11] <jodh> Ubuntu package.
[15:11] <jodh> ⛀
[15:11] <jodh>
[15:11] <doko> - PyCon week, report hopefully later ...
[15:11] <doko> - GCC-4.7 release candidates
[15:11] <doko> - GCC-4.4.7 release
[15:11] <doko> - eglibc ARM getcontext/setcontext patch
[15:11] <doko> - libgo fix for ARM
[15:12] <doko> - gdb Linaro update
[15:12] <doko> - went through the list of MIR's (three pending)
[15:12] <doko> - update python2.7 and 3.2 to the release candidates
[15:12] <doko> - package python3.3.0 alpha1 (doko/toolchain PPA)
[15:12] <doko> - PyCon sprint work: namespace peps, python core cross compilation
[15:12] <doko> (done)
[15:12] <cjwatson> ogra_: hm, jodh was working on 936667 as well - missing coordination?
[15:13] <cjwatson> ogra_: oh, sorry, never mind that, I was confused by the interleaving of your comments and ubottu's - ignore me
[15:13] <ogra_> cjwatson, i wasnt working on it, i was affected by it with my other stuff :)
[15:13] <ogra_> but the --no-log option seems to help so i can move forward now
[15:14] <ogra_> (only saw the original bug # today adn got some help from that)
[15:14] <infinity> slangasek: *nudge*
[15:14] <slangasek> still reading, gimme a second ;)
[15:15] <jodh> ogra_: just ping me if you see any other init oddities ;)
[15:15] <ogra_> jodh, i only see serial consoles that dont start by default *g*
[15:16] <infinity> jodh: I have this weird issue where, a couple of years ago, my sysvinit was replaced.  Does that count?
[15:16] <jodh> infinity: :)
[15:17] <slangasek>  * RELEASE: transition soprano off of iodbc (bug #901638)
[15:17] <slangasek>  * acpi-support upload to support a couple more events not handled elsewhere in the system (bug #931614, #953296)
[15:17] <slangasek>  * add back a few dependencies to ia32-libs for compatibility (bug #946381, #953404)
[15:17] <slangasek>  * fix a multiarch issue with libvisual-plugins that was causing weird behavior on upgrade (bug #947639)
[15:17] <slangasek>  * fix a regression in python2.7, bdb support dropped in the latest merged (bug #440889)
[15:17] <slangasek>  * SRU nis to lucid, fixing longstanding issues resulting from it not being converted to upstart
[15:17] <slangasek>  * planning for installer sprint
[15:17] <slangasek>  * partner archive work
[15:18] <slangasek> (done)
[15:18]  * doko thanks for the bdb fix ...
[15:18] <jodh> ogra_: well, technically I provided review feedback on that feature and it hasn't yet been acted on. I'll try to look at it but it's not on my priority list right now. Maybe SpamapS has some spare cycles?
[15:19] <slangasek> doko: sure
[15:19] <infinity> Done this week:
[15:19] <infinity>  - Fixed armhf FTBFS of qtwebkit-source
[15:19] <infinity>  - Worked on packaging new vmware-view-client
[15:19] <infinity>  - Worked on cdimage bugs
[15:19] <infinity>  - Patch piloted on Friday, including sponsoring a bunch of multi-arch build-dep chain fixes for cross-bootstrapping
[15:19] <infinity>  - Started looking into grub upgrade bug (bug 759545)
[15:19] <infinity>  - Started working on bug 876626
[15:19] <infinity>  - Reviewed armadaxp kernel mess for license sanity (3.2 should go in today)
[15:19] <infinity>  - Review flash-kernel changes for calxeda support (sponsoring today)
[15:19] <ogra_> jodh, well, i thought the .conf file we had was fine, isnt it just a matter of including it in the package ?
[15:19] <infinity>  - Generic archive admin and other random bits
[15:19] <infinity>  - Discussions with IS and webops about shuffling ARM buildds, upgrading some (or all) distro buildds to precise, and other fun projects
[15:19] <infinity>  - Discovered I need to keep better track of what I've done, so these cut and paste reports are a bit more useful
[15:19] <infinity>  - PS: &*^!$@ daylight savings
[15:19] <infinity> (done)
[15:19] <ogra_> infinity, move to russia !
[15:20] <doko> infinity, does the discussion include non ARM buildds as well?
[15:20] <infinity> doko: The upgrading discussion?  Yes.
[15:20] <jodh> ogra_: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/add-serial-console/+merge/46191/comments/104693
[15:20] <slangasek> infinity: do you know if anyone has a master list of outstanding issues preventing cross-bootstrapping?
[15:20] <infinity> slangasek: wookey does, but I don't have the URL off the top of my drowsy head.
[15:20] <infinity> slangasek: Poke him, or poke me after caffeine. ;)
[15:20] <slangasek> ok
[15:21] <bdmurray> bug triage
[15:21] <bdmurray> research into bug 945826 regarding sources.list on a live cd
[15:21] <bdmurray> updated dash bug reporting guidelines to mention unity
[15:21] <bdmurray> updated screenshots on h.u.c/community/BugReportingGuidelines
[15:21] <bdmurray> added in 'ubuntu-bug -w' at h.u.c/community/BugReportingGuidelines
[15:21] <bdmurray> recorded a how to confirm a bug screencast and uploaded to ubuntucontributers youtube channel
[15:21] <bdmurray> investigation into to no package bug reports (getting autoconfirmed)
[15:21] <bdmurray> uploaded new version of firefox-lp-improvements after fixing karma_suffix
[15:21] <ogra_> jodh, oh, i didnt see that
[15:21] <bdmurray> created hottest bugs charts for package sets
[15:21] <bdmurray> modified hottest and recent package bug charts to have a date updated in them
[15:21] <bdmurray> made links bold if there is a spike in this week's bug reporting volume compared to last week in recent package bug tasks
[15:21] <bdmurray> created a team assigned bug report using cbd / arsenal
[15:21] <bdmurray> bug control application review for Vadim Rutkovsky
[15:21] <bdmurray> * done *
[15:21] <slangasek> cjwatson: does 945826 ring any bells with you?
[15:22] <bdmurray> I'm not sure apt-cdrom knows about gz files
[15:22] <cjwatson> it's not the first time this has broken, I think, but it *definitely* used to work
[15:23] <cjwatson> e.g. it's faintly reminiscent of bug 924182
[15:24] <cjwatson> let me just see if I can reproduce 945826 ...
[15:24]  * slangasek nods
[15:25] <cjwatson> doko: https://rt.admin.canonical.com/Ticket/Display.html?id=50414
[15:25] <cjwatson> depending on what you mean by upgrading I guess :)
[15:25] <cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=51115 is for the software upgrade
[15:25] <slangasek> [TOPIC] installer vsprint
[15:25] <slangasek> installer virtual sprint next week
[15:26] <slangasek> (hmm, should that be 'virtual sprint, foundations' --> vsprintf?)
[15:26]  * cjwatson awards slangasek one-third of a point
[15:26]  * infinity groans.
[15:26] <cjwatson> have people looked at the first-line bug lists I suggested?  do we think it should be broadened a bit?
[15:26] <slangasek> please be sure to read through the wiki page that's been sent around with information on prep work to do ahead of time
[15:26] <slangasek> cjwatson: :)
[15:27] <cjwatson> I just wanted to get the most urgent ones down
[15:27] <slangasek> in particular, you should have both an image and a machine (VM or hardware) to install it on, ready to go Monday morning, not spend the morning downloading ISOs
[15:28] <slangasek> cjwatson: the bug lists looked to me like the right place to start
[15:28] <cjwatson> I've spoken to Nicholas Skaggs about some testing arrangements
[15:29] <cjwatson> actually I wanted to talk through that with Steve yesterday but we missed our call due to the bandwidth pixies
[15:29] <doko> does kvm work as VM?
[15:29] <slangasek> yes
[15:29] <cjwatson> we've agreed that at least we're going to try to organise something along the lines of milestone ISO testing, only based on the daily (or more) builds we emit during the sprint
[15:29] <cjwatson> and that we'll prepare a daily changelist for him so that his minions can do more focused testing work
[15:30] <slangasek> ah, cool
[15:30] <cjwatson> further ideas welcome
[15:31] <cjwatson> yes, kvm is fine for most purposes, it's what I use.  (I haven't managed to get it to pretend to be EFI well enough to boot Linux yet though, despite some attempts today)
[15:32] <stgraber> I'm running most tests in kvm too and some others (webcam, wireless, ...) in a LXC container with access to the required devices (and some hacks in ubiquity to run just the steps I need)
[15:33] <ev> so I would like to suggest that we require any changes made as part of the installer mini sprint go through code review in LP
[15:33] <ev> ideally, with two pairs of eyes on it
[15:33] <cjwatson> normally I'd suggest avoiding a monoculture, but I don't think it's especially harmful in this case - more important for people to be able to do development efficiently
[15:33] <jodh> I'm also using kvm, but doesn't that preclude Unity 3D?
[15:34] <cjwatson> I think one review should be sufficient, but I agree that we should use the review system
[15:34] <slangasek> jodh: I don't expect any of our installer bugs are going to be unity related
[15:34] <cjwatson> jodh: yes; for some bugs it matters, for most it doesn't
[15:34] <slangasek> or at least s/any/many/
[15:35] <jodh> slangasek: I wasn't necessarily thinking of the installer per se, more the resultant experience. But that was another question - when does an installer test terminate? On first reboot?
[15:35] <cjwatson> we aren't doing testing, we're doing developmenet
[15:35] <cjwatson> -e
[15:35] <jodh> or rather on first login after first reboot?
[15:35] <ogra_> on first successfull boot after installation ;)
[15:35] <slangasek> jodh: this isn't for installer testing, but for installer development :)
[15:36] <ev> ideally, I
[15:36] <cjwatson> and we're not working on the whole experience, but on the installer :)
[15:36] <ev> ideally, I'd like to see us move towards doing code review across all our projects, and I think this sprint would be a good trial run of that
[15:36] <ogra_> but we'll test the results of our work
[15:36] <slangasek> ev: agreed, I think this is a good idea
[15:36] <cjwatson> yes; but really, it's not likely that you'll need to get far enough for unity 3d to work
[15:37] <ogra_> indeed
[15:38] <cjwatson> flip side of course is that ev, stgraber, and I will probably be spending a lot of time doing reviews; but that's probably all to the good
[15:38] <ev> well, I would hope that we all do reviews
[15:38] <infinity> ev: As long as you mean "move toward a culture of code review" rather than "move to awkward processes that force busy work in the name of mandatory code review", I'm with you.
[15:38] <ev> different people will approach from different angles
[15:38] <ev> but yes, you're probably right :)
[15:38] <cjwatson> sure, but realistically ...
[15:38] <ev> absolutely
[15:38] <slangasek> jodh: many of these bugs are going to be quite self-contained; we'll want end-to-end testing after the fixes have landed, but that's why we'll have community testers coordinated to stand by
[15:39] <ev> but that's what I'm getting at with suggesting that two people review. This way we're all looking at each other's code, not just those of us most familiar with it.
[15:39] <slangasek> but you'd be hard pressed to regress the post-install desktop by fixing a bug with manual partitioning
[15:39] <cjwatson> ev: well, let's apply common sense, there's a wide range of complexity here
[15:39] <ev> sure
[15:40]  * infinity is glad he knows nothing about d-i and ubiquity.
[15:40] <cjwatson> I'm happy for reviews of complex changes to say "oh and somebody else should look at this", although I also think it's important to keep the sprint pace moving along
[15:40]  * infinity wistles nonchalantly and hides in the corner.
[15:40] <ogra_> we'll teach you !
[15:40] <slangasek> ev: so you're suggesting two reviewers, in addition to the author?
[15:41] <stgraber> +1 on common sense ;) FWIW I've always been reviewing any commit in the ubiquity branch before uploading and I'm guessing others might have done so too, we really just need to make sure it always happens and that when uploader == author, someone else looks at it before upload at least
[15:41] <slangasek> I was thinking 1 reviewer, + author, should be enough
[15:41] <slangasek> and shouldn't slow us down
[15:42] <stgraber> I'm not against using separate branches and doing merges and MP review on LP but we'll have to adapt our workflow a bit and make sure the commit and see how we can get CIA work with that :)
[15:42] <slangasek> I do think that we should view this as an opportunity for people who haven't done a lot of installer work to learn by reviewing, too
[15:42] <cjwatson> should still land trivial changes directly, as long as we have a reasonably shared understanding of that
[15:42] <infinity> stgraber: To be honest, I think MPs kinda slow the whole thing down, but maybe I'm alone in that.
[15:42] <cjwatson> (cf. e.g. Launchpad dev process)
[15:42] <ogra_> infinity, ++
[15:42]  * ogra_ prefers IRC and pastebin
[15:42] <stgraber> infinity: you're not alone :) I think MPs are fine for new features, not for bugfixes
[15:43] <ev> slangasek: yes. I think it solves the problem of only people who are intimately familiar with a codebase being the reviewers. I'm trying to increase our understanding of each other's silos with this.
[15:43] <ev> I don't think it would slow us down, as these are bug fixes. They should be fairly isolated. Equally, I think once it becomes a reflex for us to engage in code review, the pace will pick up drastically.
[15:43] <stgraber> infinity: I much prefer IRC + pastebin for trivial fixes review, just before commiting the change
[15:43] <infinity> stgraber: Unless it's a complex merge/branch that should obviously not be landed without review, for fear of exploding everything everyone else is working on.
[15:43] <infinity> stgraber: Yeah, agreed.  Lightweight, FTW.
[15:43] <ev> But I do not pretend to know for certain how it will pan out. That's why it's an experiment :)
[15:43] <slangasek> ev: well, time spent reviewing is time not spent writing your own code; so yes, I do expect there to be some slowdown no matter how we structure it
[15:44] <slangasek> but this is a good opportunity to subjectively measure that slowdown
[15:44] <infinity> ev: To be fair, most people who understand a programming language or two can review 75% (or more, made up statistics are fun) of proposed fixed just based on comparing the changelog's description of the change to the logical path the code takes.
[15:44] <ev> sorry, I meant to imply that it wont waste time. I would argue that time spent reviewing is time spent learning.
[15:44] <stgraber> if we have everyone in #ubuntu-installer, doing "bzr diff | pastebinit" before a commit and posting the URL in the channel should work fine and is really quick to do
[15:44] <slangasek> since we'll have people with varying degrees of experience with the code, and we want people to learn from their peers - exactly
[15:44] <stgraber> the main issue with that is tracability as we don't have a clear MP with the votes but well ... we have the IRC log :)
[15:45] <ev> infinity: exactly, which is why I think it's entirely reasonable that we put two bodies on every merge.
[15:45] <ev> stgraber: what's wrong with the LP code review stuff? (other than it doesn't do inline comments)
[15:45] <infinity> ev: That was actually my argument for why you only need one reviewer, even if that reviewer isn't an old skool ubuntu-installer committer. :)
[15:46] <infinity> ev: LP's code review stuff is just a bit heavyweight for a 3-line patch.
[15:46] <ev> infinity: my thought there is that when a second person comes in to review the code, they're going to be inclined to approach the code from a different angle than the one already covered
[15:46] <slangasek> ev: I don't think we should *mandate* two peers for each change, and I'm inclined to agree with cjwatson that for trivial changes we might land them with no review at all... but if any of you guys have a change that's particularly expository of an aspect of the installer code, no reason it can't be shared around
[15:46] <stgraber> ev: takes longer. You need to commit, push a separate branch, send a merge proposal, wait for LP to diff the code, have people review, then merge, commit and push
[15:46] <ev> and that by just reading what's already been said, they may learn something
[15:46] <infinity> ev: I spend more time pushing branches around than I do creating, reviewing, and committing the fix.
[15:46] <stgraber> ev: instead of doing the changes, bzr diff | pastebinit, posting to IRC, wait for a +1, commit, push
[15:46] <cjwatson> having review is more important than how the review is done
[15:47]  * slangasek nods
[15:47] <infinity> cjwatson: Crazy talk.  Next you'll imply that a submitted patch is more important than the format, and the entire open source elite will crumble.
[15:48] <cjwatson> so for complex things, sure, let's use merge proposals, otherwise, I'm easy
[15:48] <slangasek> stgraber: merge proposals have an advantage too, however, in that if the reviewer is happy, there's no additional round-trip... just land the branch directly.  So there's a bit more overhead for the author and a bit less for the reviewer
[15:48] <ev> sure, I agree with Colin's point on having review being more important. But I would like to see some clear structure to this. My hope is that we made code review a core part of what we do.
[15:48] <infinity> cjwatson: I think that's the same opinion stgraber and I had. :P
[15:48] <ev> Doesn't bzr have commands to automatically propose a branch?
[15:48] <slangasek> yes
[15:49] <cjwatson> structure is there to serve us, not the other way round :)
[15:49] <slangasek> sometimes they work :)
[15:49] <ev> lol
[15:49] <ev> cjwatson: sure, I just mean, it'd be great if there was a page I could go to in order to see the list of things awaiting comment
[15:49] <ev> rather than having to parse scrollback
[15:49] <ev> in the general sense
[15:49] <infinity> Like I said before, I want a culture of review, but I'm annoyed by attempts to force process on the whole thing.
[15:49] <ev> obviously pastebin will be easy when we're in sprint mode
[15:49] <infinity> MPs are awesome for complex merges/features.
[15:50] <infinity> Especially things that require a lot of iteration.
[15:50] <ev> mind you, I'm flexible on all of this. I am by no means saying this is the one true way to do everything.
[15:50] <cjwatson> yeah, I'll be kind of annoyed if I have to run say debconf-updatepo runs through MPs :-)
[15:51] <cjwatson> just want to make sure we're being sensible about it is all
[15:51] <infinity> We should gate all installer commits through PQM while we're at it.  *nod*
[15:51] <ev> understandable. But I'd also like to make the few lines patch fairly easy to do a MP on while still being visible in the big queue of things
[15:51] <ev> hahaha, oh dear
[15:52] <slangasek> so I don't think we have agreement on a single right way to handle merges
[15:52] <stgraber> ev: might be just me, but I'm usually flooded by LP while trafic in #ubuntu-installer is low, so I end up checking #ubuntu-installer a lot more often and read the scrollback very carefuly, I can't always say the same for all the LP merge proposals, bugs, ... (unless they are assigned to me)
[15:53] <slangasek> so let's plan to use a mix of LP MPs and pastebins (and direct commits for the trivial stuff)
[15:53] <slangasek> stgraber: ah, but you'll also be on G+ the whole time, so people can nudge you to ask for reviews directly :)
[15:53] <cjwatson> if people want to say "that's too hard for a paste, MP it" I think that's fine
[15:53] <slangasek> agreed then?
[15:54] <infinity> Works for me.
[15:54] <cjwatson> FWIW I intend to make sure everything is uploaded by the end of each day, for the purpose of daily builds
[15:54] <cjwatson> so please don't break the trunk or I'll be sad :P
[15:54] <infinity> Keep flexible, keep lower-case agile (because upper-case Agile is anything but).
[15:54] <ev> sure
[15:54] <slangasek> [TOPIC] bugs
[15:54] <slangasek> bdmurray: sorry, I haven't left you much time
[15:55] <cjwatson> fwiw I can't reproduce bug 945826
[15:55] <ev> cjwatson: are you going to be the sheriff? :)
[15:55] <ev> (context: http://www.chromium.org/developers/tree-sheriffs)
[15:55] <cjwatson> ev: pass me the silver star and the six-shooter
[15:55] <ev> lol
[15:55] <ev> you heard it here, ladies and gentlemen
[15:56] <ev> if you break trunk
[15:56] <bdmurray> slangasek: is bug 953289 related to the one you mentioned?
[15:56] <ev> cjwatson will gun you down
[15:56] <infinity> I'd rather be the tree deputy. No one ever shoots that guy.
[15:56] <ev> lol
[15:56] <slangasek> bdmurray: looking
[15:56] <bdmurray> cjwatson: what architecture did you test?
[15:56] <cjwatson> i386
[15:57] <cjwatson> don't have kubuntu-precise-desktop-amd64 locally
[15:57] <cjwatson> (would be surprised if that mattered here?)
[15:57] <bdmurray> I used ubuntu-desktop-amd64
[15:57] <slangasek> bdmurray: bug #953289 is an apt bug, fixed in precise but not in oneiric
[15:57] <cjwatson> ok, I do have that
[15:58] <slangasek> bdmurray: I see odbcinst:i386 being pulled in as a dep, and it should always have odbcinst
[15:58] <cjwatson> bdmurray: and, to be clear, you could reproduce the bug there?
[15:59] <bdmurray> cjwatson: yes apt-get update printed errors and using apt-cdrom failed too
[15:59] <cjwatson> bdmurray: hm, yes
[15:59] <slangasek> bdmurray: oh, backing up a bit, maybe there are two different issues in this log... either way, no, it's not the same bug I was talking about
[16:00]  * infinity looks at the clock.
[16:00] <bdmurray> cjwatson: I was using the apt-cdrom comand from 41apt-cdrom
[16:01] <cjwatson> bdmurray: oho, it's the *i386* entries on amd64, now I understand
[16:01] <infinity> Oh, some confusion about how multiarch should or shouldn't work WRT apt-cdrom?
[16:01] <cjwatson> running apt-cdrom is more likely to confuse than help, I think
[16:01] <slangasek> cjwatson: can I assign the bug to you for follow-through?
[16:02] <cjwatson> infinity: there's some care to try to make i386 index files available on the live CD, yes
[16:02] <cjwatson> slangasek: yep
[16:02] <slangasek> done
[16:02] <slangasek> bdmurray: any others?
[16:02] <cjwatson> looks to me like I just forgot to do it for restricted
[16:02] <infinity> cjwatson: Yeah, but having two entries seems wrong, shouldn't it just transparently DTRT if binary-i386 exists, like a file:/ or http:// URI does?
[16:03] <cjwatson> infinity: true, there's something odd there
[16:03] <bdmurray> bug 946663 - but I haven't looked into it much
[16:03] <slangasek> can we put that one in the hopper for the sprint?
[16:04]  * slangasek gives it a rls-mgr-p-tracking
[16:04] <infinity> The apt-cdrom/casper one seems vaguely installer sprinty too.
[16:05] <cjwatson> I'll fix that today, I think
[16:05] <infinity> Or that. :P
[16:05]  * cjwatson isn't planning to slow down to leave more for the installer sprint, sorry :)
[16:05] <cjwatson> running out of days ...
[16:05] <infinity> cjwatson: I'm kinda curious if the one non-arch-specified line (ie: the second line listed) is the only one present, if it DTRT WRT multi-arch.
[16:06] <cjwatson> well I was going to fix the obvious bug I see in the CD layout first
[16:06] <infinity> cjwatson: Cause if so, it's probably just a casper bug that it's adding the i386 one.
[16:06] <infinity> cjwatson: Oh, is the archive layout also not sane? :)
[16:06] <cjwatson> yep, it's entirely missing restricted/binary-i386
[16:06] <slangasek> [TOPIC] AOB
[16:06] <slangasek> anything else, or shall we adjourn? :)
[16:07] <infinity> *crickets*
[16:07] <slangasek> #endmeeting
[16:07] <meetingology> Meeting ended Wed Mar 14 16:07:48 2012 UTC.
[16:07] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-14-15.04.moin.txt
[16:07] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-14-15.04.html
[16:07] <slangasek> done
[16:07] <slangasek> thanks :)
[16:07] <ev> thanks
[16:08] <jodh> ta
[16:09] <stgraber> thanks
[17:03] <balloons> meeting time!
[17:03] <Effenberg0x0> Lag... :(
[17:03] <Effenberg0x0> Yey
[17:03] <balloons> #startmeeting ubuntu QA community meeting
[17:03] <meetingology> Meeting started Wed Mar 14 17:03:47 2012 UTC.  The chair is balloons. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:03] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[17:04] <balloons> who all is awake and ready to roll?
[17:04] <lag> Effenberg0x0: :( yourself ;)
[17:04] <phillw> o/
[17:05] <balloons> I must say the daylight savings changeover had me confused on the timeslot for this meeting
[17:05] <balloons> :-)
[17:06] <balloons> Ok, so we also have a pretty open agenda today.. no previous action
[17:06] <balloons> However, I have an open question about the wiki before we dive in... Does anyone know why the meeting log regex isn't working anymore? https://wiki.ubuntu.com/QATeam/Meetings
[17:06] <balloons> or seemingly isn't working? I don't see any of the march logs
[17:07] <balloons> lol.. I see why now :-)
[17:07] <phillw> balloons: I commented it out, I put the logs in oppostite order & it couldn't handle the two part meeting
[17:08] <balloons> hmm.. so what do we think we should do then? update manually  or ?
[17:08] <phillw> sorry, I did mean to say. I left a comment as to my update.
[17:08] <balloons> could we link part 2 of the feb 29th log to part one?
[17:08] <balloons> and leave the regex alone?
[17:09] <phillw> should be able to manually merge them,.... I'll have a look as to how it would affect the auto generated headings.
[17:09] <phillw> that meetingology uses for minutes taking.
[17:10] <balloons> ok, well I'm open to trying, but I'll open the floor for volunteers.. anyone wish to get the meeting logs sorted out?
[17:10] <balloons> you'll get a super cool action assigned to you!
[17:10] <balloons> :-)
[17:10] <phillw> h eh, as I edited it - I'll go look into it
[17:10] <balloons> thanks phillw :-)
[17:11] <balloons> [ACTION] phillw to fix feb 29th log, merge them, and make the regex for meetings page display all the logs again
[17:11] <meetingology> ACTION: phillw to fix feb 29th log, merge them, and make the regex for meetings page display all the logs again
[17:11] <balloons> ^^ see how cool that is/
[17:11] <balloons> ?
[17:11] <balloons> ok, let's move on then ;-)
[17:12] <balloons> [TOPIC] Ubuntu Updates
[17:12] <balloons> jibel, are you around?
[17:13] <balloons> hmm.. well.. I can give the updates I know about htne
[17:14] <balloons> So a couple of interesting things coming up for qa.. beta2 is happening at the end of the month as you all know.. And the team behind ubiquity and casper are having an installer sprint next week.. Mon-Weds
[17:15] <balloons> I was curious if we as a community would be interested in helping them test, report bugs, and fix critical issues that remain with the installer so it's in good shape for beta2, and of course the final release
[17:16] <phillw> balloons: I'm only aware of a few gremlins with macs still, but I'll certainly ask all lubuntu to test as soon as a daily is available
[17:16] <balloons> My idea was to have the team release an iso each day, along with a changelog of what has been fixed and we can test the following day.. So for example, after there work Monday, we would grab the iso and test during Tues and give feedback.. Repeat for Weds and thursday
[17:17] <phillw> sounds good :)
[17:17] <balloons> I don't want to add needless work to everyone's plate.. but i was thinking specific targetted testing once a day would be helpful and mostly painless :-)
[17:17] <balloons> on that note.. if you have any bugs you feel are indeed critical, let me know and I will pass them along
[17:18] <balloons> the team has a healthly list, but if the bug you have is critical and not on that list, it would be good to let them know about it
[17:19] <balloons> alrighty, I will send out an annoucement with the plan as I explained it.. and we'll do our best
[17:19] <balloons> ok, let's talk about the flavors
[17:20] <balloons> [TOPIC] Ubuntu Flavor updates
[17:20] <balloons> phillw, care to start us off with lubuntu?
[17:20] <phillw> we have the theme released and it seems to have resolved well over 90% of issues :)
[17:20] <balloons> ^^ awesome!
[17:21] <phillw> one of the others is a mac one re:ubiquity, which we hope from what you have just said to get nailed next week. That would be pretty awesome from the lubuntu point of view :)
[17:22] <phillw> that's all from lubuntu.
[17:23] <balloons> phillw, mac's do have some issues
[17:23] <balloons> we need some more people with that specific hardware to help out..
[17:23] <phillw> yeah... but progress is being made,
[17:23] <balloons> I think your spot on about focusing it a bit
[17:24] <phillw> balloons: I'm more than happy to ask our lubuntu mac people to assist.
[17:24] <balloons> thank you much phillw !
[17:24] <balloons> ok, let's move on to xubuntu
[17:25] <balloons> I'm not sure anyone else from the flavors is here today :-(
[17:25] <balloons> edubuntu, kubuntu, ubuntu studio? anyone about?
[17:27] <balloons> ok, well.. let's move on then
[17:27] <balloons> [TOPIC] Other topics
[17:27] <balloons> So, I have 2 things to share.. Before I delve in, does anyone else have anything to add?
[17:28] <balloons> Ok, first I was hoping to discuss a bit about this meeting day/time. It's become difficult for some people to make it at this day and time.. What does everyone think about possibly moving the meeting time?
[17:29] <phillw> I'm flexible as long as not at 20:00 UTC on Wednesdays!
[17:29] <balloons> do you think it's worth maybe doing a poll to see what works for everyone?
[17:30] <phillw> balloons: I think that is the method used for meeting times :)
[17:30] <balloons> [ACTION] balloons to poll community members on preferred meeting day and time
[17:30] <meetingology> ACTION: balloons to poll community members on preferred meeting day and time
[17:31] <balloons> ok, my second item is an idea I've been working on
[17:31] <balloons> having a smaller audience isn't bad for it's premiere ;-)
[17:31] <balloons> first some background
[17:32] <balloons> when i started getting more involved in QA in ubuntu, i had to learn the ropes of who was doing what, what teams existed, etc.. As part of that fact finding mission, I ended up creating a list of teams
[17:32] <balloons> http://www.theorangenotebook.com/2012/03/whos-who-on-quality-in-ubuntu.html
[17:33] <balloons> You can see my attempt to list out all the people doing QA stuff inside the ubuntu community
[17:34] <balloons> i'm sure it's missing some things/people (and if so I apologize!).. however, putting together that list made me realize how difficult it was to understand and get started in qa
[17:35] <balloons> So, I decided to think about ways we might be able to communicate better and coordinate our activities and teams
[17:35] <balloons> as well as make it easier for new community members to join us in our work
[17:35] <phillw> balloons: it looks good, Alan is pretty quick to mention accessbility is an important part of *buntu :)
[17:36] <balloons> phillw, :-)
[17:36] <balloons> So, with all that background in mind, I created this proposal.. I'll link you
[17:36] <balloons> https://wiki.ubuntu.com/QATeam/ProposedTeamStructure
[17:38] <balloons> The goals of the proposal are similar to what i just stayed.. we want to be able to communicate, recruit and retain community members, and grow.. and we want to do these things of course as effectively as we can :-)
[17:39] <phillw> an excellent idea, the easier it is for people to find about testing; the more testers we get :) Excellent work balloons
[17:39] <balloons> Now, this idea is of course simply that, an idea.. and I was wondering what everyone thought of the issues I mentioned, ways they might be solved, etc..
[17:40] <balloons> phillw, thanks.. I'm glad you like it and you want testing to grow :-)
[17:41] <balloons> Since not alot of folks where able to join today, I will of course also be sending this out to the mailing list.. It's on the wiki and people should feel free to discuss and edit it
[17:41] <phillw> balloons: whilst we are this matter, Im always open to suggestions to improve  https://wiki.ubuntu.com/Lubuntu/Testing which is the link for our Lubuntu testers.
[17:43] <balloons> phillw, perfect example.. I see us being able to collaborate on common things like testing infrastructure and process..
[17:43] <phillw> I, also, am still learning this stuff!
[17:44] <balloons> ok, great.. Well I'm happy to field any questions you have on the document or my thoughts.. If no one has anything else then we may be done early :-)
[17:45] <balloons> [ACTION] balloons to share qa team proposal to mailing list
[17:45] <meetingology> ACTION: balloons to share qa team proposal to mailing list
[17:46] <balloons> phillw, I am also still learning this stuff. I am experimenting with different ideas this cycle for testing to see what works and what doesn't.. so we might be able to move forward next cycle with more structure and knowledge behind us
[17:47] <phillw> +1, the mac testers are all completely new - it has given me an excellent insight into what newcomers need to support them.
[17:48] <balloons> awesome.. that's the stuff we can all learn from and share..
[17:48] <balloons> ok, I'll end us for this week.. thanks for coming everyone
[17:48] <balloons> #endmeeting
[17:48] <meetingology> Meeting ended Wed Mar 14 17:48:14 2012 UTC.
[17:48] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-14-17.03.moin.txt
[17:48] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-14-17.03.html
[18:02] <bdmurray> time for the bug squad meeting!
[18:02] <bdmurray> #startmeeting
[18:02] <meetingology> Meeting started Wed Mar 14 18:02:23 2012 UTC.  The chair is bdmurray. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:02] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:02] <bdmurray> #topic Previous Actions
[18:02] <bdmurray> ACTION: put list of dbus no reply bugs into a wiki page and email bugsquad regarding list: bdmurray
[18:03] <bdmurray> so I ended up just taking care of the dbus no reply bugs myself
[18:03] <bdmurray> so we can consider that done
[18:03] <bdmurray> that was the only action item from last week
[18:04] <bdmurray> #topic Engineering Team Bug Status
[18:04] <bdmurray> next week the foundations team is having an installer virtual sprint so that should be exciting
[18:05] <bdmurray> this past week I made a very short how to confirm a bug task video
[18:06] <bdmurray> http://youtu.be/Vl-cQDAlPFc
[18:06] <bdmurray> I plan on making some oethers but if you want to help let me know
[18:07] <bdmurray> I also updated screenshots and some documentation at help.ubuntu.com/community/BugReportingGuidelines
[18:07] <bdmurray> and I've uploaded a new version of firefox-lp-improvements which fixed a bug in the gmane link to a users bug activity
[18:08] <bdmurray> Ursinha: do you have anything?
[18:09] <bdmurray> jsalisbury: anything interesting happening in kernel land?
[18:10] <jsalisbury> There is an increase of bugs related to Lenovo ThinkPads overheating.
[18:10] <jsalisbury> However, it doesn't seem to be a regression, since I was able to reproduce the issue in Oneiric and Natty.
[18:10] <bdmurray> I've a thinkpad! what do I need to know
[18:11] <jsalisbury> If you run a very hight load, basically keeping the cpu at 100% utilized, the laptop may hit 100C and crash.
[18:11] <jsalisbury> It appears to be BIOS related, but the kernel team is getting in touch with Lenovo to see if we can overide the fan control in the thinkpad_acpi driver
[18:12] <bdmurray> jsalisbury: thanks, that is good to know
[18:12] <jsalisbury> The bug is bug 751689
[18:12] <jsalisbury> I can only reproduce it by running multiple kernel compiles at the same time.
[18:13] <jsalisbury> An partially blocking the fan exhaust, which may happen if you use the laptop "On your lap"
[18:13] <jsalisbury> :-)
[18:13] <bdmurray> heh
[18:13] <jsalisbury> We are also still keeping an eye out for any new RC6 related bugs.
[18:13] <jsalisbury> ..
[18:13] <Ursinha> I have nothing specific to report
[18:14] <Ursinha> unity related bugs stopped showing
[18:14] <Ursinha> rephrasing: unity bugs similar to what we had after beta 1 stopped showing
[18:14] <Ursinha> that must mean situation is under control now :)
[18:15] <bdmurray> I also made some more changes to the recent package bug graphs
[18:15] <bdmurray> for example http://reports.qa.ubuntu.com/reports/ubuntu-desktop/desktop-packages-recent-bug-tasks.html
[18:16] <bdmurray> labels now say this week and last week
[18:16] <bdmurray> the this week link becomes bold if this week > last week
[18:16] <Ursinha> I like it bdmurray
[18:16] <bdmurray> and there's a bit that says when the json file was updated
[18:17] <bdmurray> thanks Ursinha
[18:17] <bdmurray> moving on
[18:17] <bdmurray> #topic Bug Escalations (any High or Critical bugs that community members have seen that need attention)
[18:18] <wagafo> Somebody found a workaround to bug 527157  and bug 839281 that suggests adding a parameter at boot for the kernel. Could these bugs be in the kernel instead of gnome-power-manager and friends (the bug has been around for 2 years...).
[18:19] <bdmurray> wagafo: what comment has the workaround?
[18:19] <wagafo> Sorry if this is not "high or critical" and does not belong. The workaround is adding a paramter for the kernel at boot.
[18:20] <bdmurray> oh maybe its the one that starts "Happy Birthday Bug ..."
[18:20] <bdmurray> jsalisbury: can you look at these?
[18:21] <jsalisbury> bdmurray, wagafo, sure I'll take a look and move them over to the kernel package if needed.
[18:22] <bdmurray> wagafo: while it isn't a high or critical bug thanks for bringing it up
[18:23] <wagafo> bdmurray: I have a couple more, should I also mention them?
[18:23] <bdmurray> wagafo: if a couple really means 2 sure. ;-)
[18:23] <wagafo> Bug 807259 seems to have all information and seems to me be easy to decide to weather fix or won't fix.
[18:23] <bdmurray> okay, I'll take that one
[18:24] <wagafo> And the last one: Bug 872207. Can it be marked as triaged?
[18:26] <bdmurray> Ursinha: can you look at that one?
[18:28] <bdmurray> wagafo: it looks like 872207 is incomplete and looking for some feedback
[18:29] <wagafo> bdmurray: OK, let me then go back to it and see if I can more info from the reporters
[18:29] <bdmurray> wagafo: also the description could use a better test case / steps to recreate the bug
[18:30] <wagafo> bdmurray: Ok, we'll try to improve the info there
[18:30] <bdmurray> wagafo: okay great thanks!
[18:30] <bdmurray> any other bugs we should be aware of?
[18:32] <bdmurray> #topic any other business
[18:32] <bdmurray> anything else worth discussing?
[18:33] <bdmurray> wagafo: if you run into other bugs you are concerned about feel free to use the bugsquad mailing list too
[18:33] <wagafo> bdmurray: OK
[18:35] <bdmurray> okay thanks everyone
[18:35] <bdmurray> #endmeeting
[18:35] <meetingology> Meeting ended Wed Mar 14 18:35:56 2012 UTC.
[18:35] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-14-18.02.moin.txt
[18:35] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-14-18.02.html
[18:39] <jsalisbury> bdmurray, Thanks!
[20:03]  * oCean jumps
[20:03] <topyli> how high?
[20:04] <oCean> oh, only a little bit.. don't want to worry the neighbours
[20:05] <topyli> ok :(
[20:05] <Pici> I will be driving for a little bit, so I may be a little late...
[20:06] <topyli> don't irc and drive!
[20:07] <oCean> drive only between the lines
[20:07] <jalcine> heh
[20:08] <oCean> quite a turnout for the team meeting..
[20:09] <Unit193> I'm here, but that doesn't count. :/
[20:10] <moergaes> So, is there a meeting after all?
[20:10] <oCean> Sure it does!
[20:10] <Unit193> moergaes: Lubuntu meeting is in #lubuntu-offtopic
[20:12] <moergaes> I didn't know we had an offtopic...
[20:13] <topyli> hm, i even have my timezones right this time
[20:13] <topyli> AlanBell, tsimpson?
[20:13] <oCean> (-:
[20:14]  * tsimpson is not on the council :)
[20:14] <topyli> the standard academic fifteen is almost gone
[20:14] <topyli> tsimpson: oh, you're not :)
[20:15] <oCean> FUNKEH!?
[20:15] <topyli> i don't see funky hats either :(
[20:15] <oCean> Oh boy, what should we do now!!
[20:15] <tsimpson> give it until :30 and then just postpone, I guess
[20:16] <topyli> yeah
[20:16] <tsimpson> if people get here around :30, you guys can pick a day/time and then postpone. probably not going to get much done in 30 mins anyway
[20:17] <tsimpson> though it's not like we don't usually overrun :)
[20:17] <oCean> well, there is not much on the agenda
[20:17] <topyli> AlanBell is a pretty good chair though
[20:17] <oCean> sure
[20:18] <topyli> nothing on the agenda is super urgent. no member prospects sweating here or anything like that
[20:18] <oCean> if we go quickly through the more-or-less-fixed items, we can make it in half an hour I guess
[20:19] <topyli> i don't mind if we go overtime, it's late in the evening so it's not like i'm going anywhere
[20:32] <topyli> alright. i think we'll just postpone due to lack of quorum. we'll send mail some time tomorrow and see what sort of time we've managed to come up with
[20:32] <jussi> you all suck! down with the IRCC!! :P :P  (heckling anyone?) :P :P
[20:33] <topyli> thanks and apologies to those who came
[20:33] <topyli> not jussi though, of course :)
[20:33]  * jussi hugs topyli
[20:33] <jussi> and then throws eggs
[20:33] <oCean> :)
[20:33] <topyli> mmm, eggs
[20:33]  * topyli rubs yolk in hair
[20:34] <Unit193> Nice, now you don't need a shower! :D
[20:35] <topyli> exactly. what a time saver!
[21:12] <AlanBell> erk
[21:12] <AlanBell> hi all, sorry