15:04:14 <slangasek> #startmeeting
15:04:14 <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:14 <meetingology> 
15:04:14 <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:46 <slangasek> [TOPIC] lightning round
15:04:48 <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra infinity cjwatson)
15:04:51 <slangasek> cjwatson ev stgraber barry ogra jodh doko slangasek infinity bdmurray
15:06:02 <cjwatson> Release meeting:
15:06:02 <cjwatson> - Do a better job of writing hybrid MBRs on Intel Macs (bug 856826).
15:06:02 <cjwatson> - Reuse existing swap partitions and EFI System Partitions rather than creating new ones (bug 311299).
15:06:05 <ubottu> Launchpad bug 856826 in parted (Ubuntu Precise) "'guided resize' partioning leaves Mac unbootable" [High,Fix released] https://launchpad.net/bugs/856826
15:06:06 <ubottu> Launchpad bug 311299 in partman-auto (Ubuntu) "automatic partitioning does not reuse existing swap / boot partitions" [Wishlist,Fix released] https://launchpad.net/bugs/311299
15:06:06 <cjwatson> - Arrange for Ubuntu Studio images to reconfigure jackd on boot (bug 923810).
15:06:07 <ubottu> Launchpad bug 923810 in casper (Ubuntu) "preseeding passwd/user-default-groups is ineffective" [Medium,Fix released] https://launchpad.net/bugs/923810
15:06:09 <cjwatson> - Work on several EFI partitioning bugs (bug 769669, bug 811485).
15:06:11 <ubottu> Launchpad bug 769669 in partman-efi (Ubuntu) "Installer should not format an existing EFI System Partition" [High,Fix released] https://launchpad.net/bugs/769669
15:06:12 <cjwatson> Other:
15:06:12 <ubottu> Launchpad bug 811485 in partman-efi (Ubuntu) "EFI SYSTEM PARTITION should be atleast 100 MiB size and formatted as FAT32, not FAT16" [High,Fix released] https://launchpad.net/bugs/811485
15:06:14 <cjwatson> - Planning for installer sprint.
15:06:17 <cjwatson> - Some work on setting interview problems.
15:06:19 <cjwatson> - Various installer translation updates.
15:06:22 <cjwatson> - Multiarch fixes for pciutils (bug 948205) and libidl (bug 931388).
15:06:24 <ubottu> Launchpad bug 948205 in pciutils (Debian) " './usr/include/pci/config.h' is different from the same file on the system" [Unknown,New] https://launchpad.net/bugs/948205
15:06:24 <cjwatson> - Improve debootstrap's handling of corrupted downloads (bug 954197).
15:06:25 <ubottu> Launchpad bug 931388 in wine1.4 (Ubuntu Precise) "overenthusiastic adoption of "Depends: cpp:any" syntax" [High,Fix released] https://launchpad.net/bugs/931388
15:06:26 <ubottu> Launchpad bug 954197 in base-installer (Ubuntu) "base system installation is not robust against transient network failures" [Medium,Triaged] https://launchpad.net/bugs/954197
15:06:27 <cjwatson> - Upgrade fixes for desktopcouch (bug 864328, bug 900570).
15:06:28 <ubottu> Launchpad bug 864328 in desktopcouch (Ubuntu) "package python-desktopcouch-records 1.0.7-0ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/pyshared/desktopcouch/__init__.py', which is also in package python-desktopcouch 0.6.4-0ubuntu3.2" [Undecided,Fix released] https://launchpad.net/bugs/864328
15:06:29 <ubottu> Launchpad bug 900570 in desktopcouch (Ubuntu) "undeclared package conflict between python-desktopcouch-application (in precise) and python-desktopcouch (in lucid)" [Undecided,Fix released] https://launchpad.net/bugs/900570
15:06:30 <cjwatson> - Currently trying to get my head around some more Mac partitioning bugs: bug 855871 and bug 856763.  Brain hurts, send cake.
15:06:31 <ubottu> Launchpad bug 855871 in ubiquity (Ubuntu Oneiric) "Grub install fails after manual xfs partitioning" [Medium,Confirmed] https://launchpad.net/bugs/855871
15:06:32 <cjwatson> ..
15:06:33 <ubottu> Launchpad bug 856763 in parted (Ubuntu Precise) "Mac cannot boot after manual partitioning, unless using ext4" [Medium,Confirmed] https://launchpad.net/bugs/856763
15:06:55 <ev> - Ported the daisy code from Pika to amqplib, as that's what all other
15:06:56 <ev> Canonical services are using.
15:06:57 <ev> - Build out a configuration for retracing machines.
15:06:58 <ev> - Bug fixes in the WSGI applications (crash and core file acceptance).
15:06:59 <ev> - Packaging oops-repository, python-pycassa, and python-thrift for IS (RT 48667)
15:07:02 <ev> - Refactored whoopsie and broke out some separate utility code, adding tests
15:07:03 <ev> for all of it along the way.  This was in support of fixing how we determine
15:07:04 <ev> whether or not to submit a crash. Previously, we were only sending them on
15:07:06 <ev> the first instance. We now send it every time that crash occurs.
15:07:06 <ev> - Did research and performance measurements around counting the contents of
15:07:07 <ev> crash buckets in Cassandra.
15:07:09 <ev> - Finished initial bucketing code. There may be room for improvement around
15:07:10 <ev> how we're counting and recording bucket sizes, but some real idea from the
15:07:11 <ev> deployment will give me a much better indication.
15:07:12 <ev> - Built a test harness around the WSGI applications (crash and core file
15:07:14 <ev> acceptance). Already quite a few serious fixes from this. Yay.
15:07:15 <ev> - Started moving Cassandra-facing functionality into oops-repository, per my
15:07:17 <ev> discussion with Robert last week where he made the suggestion to use it
15:07:18 <ev> alone as the layer over the database.
15:07:19 <ev> - Meeting with Amanda to discuss keeping her in the loop with respect to
15:07:21 <ev> changes to ubuntu-restricted-*
15:07:21 <ev> (done)
15:08:03 <stgraber> Bugs, bugs, bugs...
15:08:03 <stgraber> - Networking
15:08:03 <stgraber> - RELEASE: Uploaded new isc-dhcp, converting to upstart and creating separate IPv4 and IPv6 jobs
15:08:06 <stgraber> - Investigated bug 919068 (bridge_ports all not working at boot time)
15:08:07 <ubottu> Launchpad bug 919068 in bridge-utils (Ubuntu) "bridge_ports all doesn't work at boot time" [Medium,Triaged] https://launchpad.net/bugs/919068
15:08:08 <stgraber> - Installer
15:08:11 <stgraber> - RELEASE (generic): Bugfix work on ubiquity, casper and wubi
15:08:13 <stgraber> - Went through wubi merge proposals, merged a lot of bugfixes from bcbc
15:08:16 <stgraber> - Started going through the wubi bugs too
15:08:18 <stgraber> - Spent some time implementing bluetooth support in the installer
15:08:21 <stgraber> - Fixed the keyboard indicator
15:08:23 <stgraber> - Fixed a few bugs in casper related to persistent usb stick
15:08:26 <stgraber> - Various other ubiquity fixes and a few improvements to tests
15:08:28 <stgraber> - Containers
15:08:31 <stgraber> - Worked/debugged apparmor and LXC with the security team, hoping to have an updated lxc today
15:08:34 <stgraber> - TPM
15:08:37 <stgraber> - Started digging into opencryptoki, fixed bug 926305
15:08:38 <ubottu> Launchpad bug 926305 in opencryptoki (Ubuntu) "fails to load modules for pkcs11 backends" [Undecided,Fix released] https://launchpad.net/bugs/926305
15:08:39 <stgraber> - Other
15:08:42 <stgraber> - RELEASE: Merged James' friendly-recovery branch adding support for LVM and APT status to the system-summary screen
15:08:45 <stgraber> - Had to deal with a security issue found in LTSP, fixing upstream and in Ubuntu + CVE and other paperwork
15:08:48 <stgraber> - Patch pilot on Monday
15:08:51 <stgraber> - TODO this week
15:08:53 <stgraber> - Work on some ubiquity debugging wiki pages
15:08:55 <stgraber> - Continue working on bugs
15:08:58 <stgraber> (DONE)
15:09:58 <doko> heh, barry doesn't seem to be awake
15:10:47 <doko> ogra: ^^^
15:10:59 <ogra_> done:
15:11:00 <ogra_> * not gotten to oem-config issues, will do so next week
15:11:00 <ogra_> * trying to stopwatchg the initrd made me struggle on bug 936667 (--no-log helps)
15:11:00 <ogra_> * did some more weeding through ubuntu-arm buglist (starts to look more sane)
15:11:00 <ogra_> * missed my piloting on monday, will try to do before teh weekend
15:11:00 <ogra_> * worked on Bug 948163 (fix in local branch, pending a push)
15:11:01 <ubottu> Launchpad bug 936667 in upstart (Ubuntu) "Upstart early job logging causes boot failure for systems with no initramfs (error is "No available ptys")" [High,Confirmed] https://launchpad.net/bugs/936667
15:11:02 <ogra_> * lots of community support issues (helped RTC issues with arm devices)
15:11:03 <ubottu> Launchpad bug 948163 in casper (Ubuntu) "System suspends upon closing the lid while installing/partitioning using a live CD" [Wishlist,New] https://launchpad.net/bugs/948163
15:11:04 <ogra_> * looked into a few ac100 installer bugs
15:11:06 <ogra_> * booked my flight to UDS
15:11:08 <ogra_> tod:
15:11:10 <ogra_> * oem-config (this week for sure)
15:11:12 <ogra_> * finish initrd timing
15:11:14 <ogra_> * lookj into fsck delay on boot issue
15:11:19 <ogra_> done
15:11:32 <jodh> Off sick Monday. Been hit by bug 751689 this week which has hampered
15:11:32 <jodh> efforts somewhat until I realized what was happening. Investigated
15:11:32 <jodh> bug 940396. Initially thought it might be multi-arch related, but
15:11:32 <jodh> seemingly its a subtle dependency bug: mvo has now recreated and
15:11:34 <ubottu> Launchpad bug 751689 in linux (Ubuntu Maverick) "ThinkPads overheat due to slow fans when on 'auto'" [Critical,In progress] https://launchpad.net/bugs/751689
15:11:35 <ubottu> Launchpad bug 940396 in apt (Ubuntu Precise) "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/940396
15:11:36 <jodh> identified fixes. Worked on bug 508083 (currently testing). Writing some
15:11:37 <ubottu> Launchpad bug 508083 in eglibc (Ubuntu) "cron crashed with SIGSEGV in __pthread_initialize_minimal_internal()" [Medium,Triaged] https://launchpad.net/bugs/508083
15:11:39 <jodh> new tests for Upstart as a precursor to syncing branches and updating
15:11:42 <jodh> Ubuntu package.
15:11:45 <jodh> ⛀
15:11:49 <jodh> 
15:11:59 <doko> - PyCon week, report hopefully later ...
15:11:59 <doko> - GCC-4.7 release candidates
15:11:59 <doko> - GCC-4.4.7 release
15:11:59 <doko> - eglibc ARM getcontext/setcontext patch
15:11:59 <doko> - libgo fix for ARM
15:12:00 <doko> - gdb Linaro update
15:12:01 <doko> - went through the list of MIR's (three pending)
15:12:03 <doko> - update python2.7 and 3.2 to the release candidates
15:12:06 <doko> - package python3.3.0 alpha1 (doko/toolchain PPA)
15:12:10 <doko> - PyCon sprint work: namespace peps, python core cross compilation
15:12:12 <doko> (done)
15:12:42 <cjwatson> ogra_: hm, jodh was working on 936667 as well - missing coordination?
15:13:14 <cjwatson> ogra_: oh, sorry, never mind that, I was confused by the interleaving of your comments and ubottu's - ignore me
15:13:24 <ogra_> cjwatson, i wasnt working on it, i was affected by it with my other stuff :)
15:13:47 <ogra_> but the --no-log option seems to help so i can move forward now
15:14:24 <ogra_> (only saw the original bug # today adn got some help from that)
15:14:41 <infinity> slangasek: *nudge*
15:14:57 <slangasek> still reading, gimme a second ;)
15:15:05 <jodh> ogra_: just ping me if you see any other init oddities ;)
15:15:36 <ogra_> jodh, i only see serial consoles that dont start by default *g*
15:16:01 <infinity> jodh: I have this weird issue where, a couple of years ago, my sysvinit was replaced.  Does that count?
15:16:09 <jodh> infinity: :)
15:17:27 <slangasek> * RELEASE: transition soprano off of iodbc (bug #901638)
15:17:27 <slangasek> * acpi-support upload to support a couple more events not handled elsewhere in the system (bug #931614, #953296)
15:17:28 <ubottu> Launchpad bug 901638 in soprano (Debian) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [Unknown,New] https://launchpad.net/bugs/901638
15:17:30 <slangasek> * add back a few dependencies to ia32-libs for compatibility (bug #946381, #953404)
15:17:31 <ubottu> Launchpad bug 931614 in acpi-support (Ubuntu) "ASUS backlit keys buttons don't work" [Medium,Fix released] https://launchpad.net/bugs/931614
15:17:32 <ubottu> Launchpad bug 953296 in acpi-support (Ubuntu) "Elantech touchpad cannot be toggled" [Medium,Fix released] https://launchpad.net/bugs/953296
15:17:33 <slangasek> * fix a multiarch issue with libvisual-plugins that was causing weird behavior on upgrade (bug #947639)
15:17:34 <ubottu> Launchpad bug 946381 in ia32-libs (Ubuntu) "Should install libxtst6:i386" [Medium,Fix released] https://launchpad.net/bugs/946381
15:17:36 <slangasek> * fix a regression in python2.7, bdb support dropped in the latest merged (bug #440889)
15:17:39 <slangasek> * SRU nis to lucid, fixing longstanding issues resulting from it not being converted to upstart
15:17:42 <slangasek> * planning for installer sprint
15:17:42 <ubottu> Launchpad bug 953404 in ia32-libs (Ubuntu) "ia32-libs in precise is missing libgconf-2-4:i386" [Undecided,Fix released] https://launchpad.net/bugs/953404
15:17:44 <ubottu> Launchpad bug 947639 in apt (Ubuntu) "package libgudev-1.0-0 1:175-0ubuntu5 failed to install/upgrade: libgudev-1.0-0:amd64 1" [High,New] https://launchpad.net/bugs/947639
15:17:45 <slangasek> * partner archive work
15:17:47 <ubottu> Launchpad bug 440889 in python2.7 (Ubuntu Precise) "software-center crashed with ImportError in /usr/lib/python2.7/bsddb/__init__.py: No module named _bsddb" [Critical,Fix released] https://launchpad.net/bugs/440889
15:18:32 <slangasek> (done)
15:18:45 * doko thanks for the bdb fix ...
15:18:52 <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:13 <slangasek> doko: sure
15:19:18 <infinity> Done this week:
15:19:18 <infinity> - Fixed armhf FTBFS of qtwebkit-source
15:19:18 <infinity> - Worked on packaging new vmware-view-client
15:19:18 <infinity> - Worked on cdimage bugs
15:19:18 <infinity> - Patch piloted on Friday, including sponsoring a bunch of multi-arch build-dep chain fixes for cross-bootstrapping
15:19:21 <infinity> - Started looking into grub upgrade bug (bug 759545)
15:19:22 <ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
15:19:23 <infinity> - Started working on bug 876626
15:19:25 <ubottu> Launchpad bug 876626 in upstart (Ubuntu Precise) "Unlocking the second crypto disk (/home) echos password on console" [High,Confirmed] https://launchpad.net/bugs/876626
15:19:26 <infinity> - Reviewed armadaxp kernel mess for license sanity (3.2 should go in today)
15:19:29 <infinity> - Review flash-kernel changes for calxeda support (sponsoring today)
15:19:29 <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:32 <infinity> - Generic archive admin and other random bits
15:19:34 <infinity> - Discussions with IS and webops about shuffling ARM buildds, upgrading some (or all) distro buildds to precise, and other fun projects
15:19:37 <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:40 <infinity> - PS: &*^!$@ daylight savings
15:19:43 <infinity> (done)
15:19:54 <ogra_> infinity, move to russia !
15:20:06 <doko> infinity, does the discussion include non ARM buildds as well?
15:20:18 <infinity> doko: The upgrading discussion?  Yes.
15:20:19 <jodh> ogra_: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/add-serial-console/+merge/46191/comments/104693
15:20:23 <slangasek> infinity: do you know if anyone has a master list of outstanding issues preventing cross-bootstrapping?
15:20:44 <infinity> slangasek: wookey does, but I don't have the URL off the top of my drowsy head.
15:20:53 <infinity> slangasek: Poke him, or poke me after caffeine. ;)
15:20:57 <slangasek> ok
15:21:00 <bdmurray> bug triage
15:21:00 <bdmurray> research into bug 945826 regarding sources.list on a live cd
15:21:01 <bdmurray> updated dash bug reporting guidelines to mention unity
15:21:01 <bdmurray> updated screenshots on h.u.c/community/BugReportingGuidelines
15:21:02 <ubottu> Launchpad bug 945826 in apt (Ubuntu) "12.04 AMD64 Beta Live CD sources.list has a bad entry" [Medium,Triaged] https://launchpad.net/bugs/945826
15:21:11 <bdmurray> added in 'ubuntu-bug -w' at h.u.c/community/BugReportingGuidelines
15:21:11 <bdmurray> recorded a how to confirm a bug screencast and uploaded to ubuntucontributers youtube channel
15:21:14 <bdmurray> investigation into to no package bug reports (getting autoconfirmed)
15:21:16 <bdmurray> uploaded new version of firefox-lp-improvements after fixing karma_suffix
15:21:17 <ogra_> jodh, oh, i didnt see that
15:21:21 <bdmurray> created hottest bugs charts for package sets
15:21:21 <bdmurray> modified hottest and recent package bug charts to have a date updated in them
15:21:24 <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:27 <bdmurray> created a team assigned bug report using cbd / arsenal
15:21:31 <bdmurray> bug control application review for Vadim Rutkovsky
15:21:36 <bdmurray> * done *
15:21:44 <slangasek> cjwatson: does 945826 ring any bells with you?
15:22:31 <bdmurray> I'm not sure apt-cdrom knows about gz files
15:22:45 <cjwatson> it's not the first time this has broken, I think, but it *definitely* used to work
15:23:26 <cjwatson> e.g. it's faintly reminiscent of bug 924182
15:23:27 <ubottu> Launchpad bug 924182 in apt (Ubuntu Precise) "d-i images (server, alternate) failed to install: no kernels found" [Critical,Fix released] https://launchpad.net/bugs/924182
15:24:13 <cjwatson> let me just see if I can reproduce 945826 ...
15:24:42 * slangasek nods
15:25:05 <cjwatson> doko: https://rt.admin.canonical.com/Ticket/Display.html?id=50414
15:25:21 <cjwatson> depending on what you mean by upgrading I guess :)
15:25:33 <cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=51115 is for the software upgrade
15:25:34 <slangasek> [TOPIC] installer vsprint
15:25:55 <slangasek> installer virtual sprint next week
15:26:05 <slangasek> (hmm, should that be 'virtual sprint, foundations' --> vsprintf?)
15:26:20 * cjwatson awards slangasek one-third of a point
15:26:51 * infinity groans.
15:26:53 <cjwatson> have people looked at the first-line bug lists I suggested?  do we think it should be broadened a bit?
15:26:54 <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:59 <slangasek> cjwatson: :)
15:27:10 <cjwatson> I just wanted to get the most urgent ones down
15:27:32 <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:48 <slangasek> cjwatson: the bug lists looked to me like the right place to start
15:28:49 <cjwatson> I've spoken to Nicholas Skaggs about some testing arrangements
15:29:08 <cjwatson> actually I wanted to talk through that with Steve yesterday but we missed our call due to the bandwidth pixies
15:29:36 <doko> does kvm work as VM?
15:29:41 <slangasek> yes
15:29:41 <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:58 <cjwatson> and that we'll prepare a daily changelist for him so that his minions can do more focused testing work
15:30:10 <slangasek> ah, cool
15:30:34 <cjwatson> further ideas welcome
15:31:18 <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:26 <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:27 <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:33 <ev> ideally, with two pairs of eyes on it
15:33:34 <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:59 <jodh> I'm also using kvm, but doesn't that preclude Unity 3D?
15:34:03 <cjwatson> I think one review should be sufficient, but I agree that we should use the review system
15:34:15 <slangasek> jodh: I don't expect any of our installer bugs are going to be unity related
15:34:23 <cjwatson> jodh: yes; for some bugs it matters, for most it doesn't
15:34:38 <slangasek> or at least s/any/many/
15:35:33 <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:55 <cjwatson> we aren't doing testing, we're doing developmenet
15:35:56 <cjwatson> -e
15:35:56 <jodh> or rather on first login after first reboot?
15:35:56 <ogra_> on first successfull boot after installation ;)
15:35:57 <slangasek> jodh: this isn't for installer testing, but for installer development :)
15:36:01 <ev> ideally, I
15:36:20 <cjwatson> and we're not working on the whole experience, but on the installer :)
15:36:21 <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:33 <ogra_> but we'll test the results of our work
15:36:51 <slangasek> ev: agreed, I think this is a good idea
15:36:55 <cjwatson> yes; but really, it's not likely that you'll need to get far enough for unity 3d to work
15:37:03 <ogra_> indeed
15:38:04 <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:18 <ev> well, I would hope that we all do reviews
15:38:21 <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:24 <ev> different people will approach from different angles
15:38:32 <ev> but yes, you're probably right :)
15:38:37 <cjwatson> sure, but realistically ...
15:38:42 <ev> absolutely
15:38:56 <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:11 <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:17 <slangasek> but you'd be hard pressed to regress the post-install desktop by fixing a bug with manual partitioning
15:39:32 <cjwatson> ev: well, let's apply common sense, there's a wide range of complexity here
15:39:43 <ev> sure
15:40:07 * infinity is glad he knows nothing about d-i and ubiquity.
15:40:26 <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:27 * infinity wistles nonchalantly and hides in the corner.
15:40:29 <ogra_> we'll teach you !
15:40:47 <slangasek> ev: so you're suggesting two reviewers, in addition to the author?
15:41:07 <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:30 <slangasek> I was thinking 1 reviewer, + author, should be enough
15:41:57 <slangasek> and shouldn't slow us down
15:42:00 <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:22 <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:31 <cjwatson> should still land trivial changes directly, as long as we have a reasonably shared understanding of that
15:42:33 <infinity> stgraber: To be honest, I think MPs kinda slow the whole thing down, but maybe I'm alone in that.
15:42:38 <cjwatson> (cf. e.g. Launchpad dev process)
15:42:47 <ogra_> infinity, ++
15:42:55 * ogra_ prefers IRC and pastebin
15:42:56 <stgraber> infinity: you're not alone :) I think MPs are fine for new features, not for bugfixes
15:43:06 <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:07 <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:09 <stgraber> infinity: I much prefer IRC + pastebin for trivial fixes review, just before commiting the change
15:43:09 <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:21 <infinity> stgraber: Yeah, agreed.  Lightweight, FTW.
15:43:35 <ev> But I do not pretend to know for certain how it will pan out. That's why it's an experiment :)
15:43:53 <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:17 <slangasek> but this is a good opportunity to subjectively measure that slowdown
15:44:31 <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:32 <ev> sorry, I meant to imply that it wont waste time. I would argue that time spent reviewing is time spent learning.
15:44:40 <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:49 <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:58 <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:02 <ev> infinity: exactly, which is why I think it's entirely reasonable that we put two bodies on every merge.
15:45:33 <ev> stgraber: what's wrong with the LP code review stuff? (other than it doesn't do inline comments)
15:45:37 <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:04 <infinity> ev: LP's code review stuff is just a bit heavyweight for a 3-line patch.
15:46:08 <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:13 <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:15 <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:19 <ev> and that by just reading what's already been said, they may learn something
15:46:24 <infinity> ev: I spend more time pushing branches around than I do creating, reviewing, and committing the fix.
15:46:34 <stgraber> ev: instead of doing the changes, bzr diff | pastebinit, posting to IRC, wait for a +1, commit, push
15:46:39 <cjwatson> having review is more important than how the review is done
15:47:20 * slangasek nods
15:47:24 <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:00 <cjwatson> so for complex things, sure, let's use merge proposals, otherwise, I'm easy
15:48:16 <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:30 <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:31 <infinity> cjwatson: I think that's the same opinion stgraber and I had. :P
15:48:51 <ev> Doesn't bzr have commands to automatically propose a branch?
15:48:59 <slangasek> yes
15:49:02 <cjwatson> structure is there to serve us, not the other way round :)
15:49:02 <slangasek> sometimes they work :)
15:49:05 <ev> lol
15:49:31 <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:36 <ev> rather than having to parse scrollback
15:49:39 <ev> in the general sense
15:49:45 <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:47 <ev> obviously pastebin will be easy when we're in sprint mode
15:49:54 <infinity> MPs are awesome for complex merges/features.
15:50:00 <infinity> Especially things that require a lot of iteration.
15:50:09 <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:27 <cjwatson> yeah, I'll be kind of annoyed if I have to run say debconf-updatepo runs through MPs :-)
15:51:08 <cjwatson> just want to make sure we're being sensible about it is all
15:51:12 <infinity> We should gate all installer commits through PQM while we're at it.  *nod*
15:51:21 <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:25 <ev> hahaha, oh dear
15:52:35 <slangasek> so I don't think we have agreement on a single right way to handle merges
15:52:37 <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:10 <slangasek> so let's plan to use a mix of LP MPs and pastebins (and direct commits for the trivial stuff)
15:53:29 <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:36 <cjwatson> if people want to say "that's too hard for a paste, MP it" I think that's fine
15:53:57 <slangasek> agreed then?
15:54:04 <infinity> Works for me.
15:54:11 <cjwatson> FWIW I intend to make sure everything is uploaded by the end of each day, for the purpose of daily builds
15:54:18 <cjwatson> so please don't break the trunk or I'll be sad :P
15:54:20 <infinity> Keep flexible, keep lower-case agile (because upper-case Agile is anything but).
15:54:20 <ev> sure
15:54:46 <slangasek> [TOPIC] bugs
15:54:58 <slangasek> bdmurray: sorry, I haven't left you much time
15:55:02 <cjwatson> fwiw I can't reproduce bug 945826
15:55:03 <ev> cjwatson: are you going to be the sheriff? :)
15:55:04 <ubottu> Launchpad bug 945826 in apt (Ubuntu) "12.04 AMD64 Beta Live CD sources.list has a bad entry" [Medium,Triaged] https://launchpad.net/bugs/945826
15:55:28 <ev> (context: http://www.chromium.org/developers/tree-sheriffs)
15:55:39 <cjwatson> ev: pass me the silver star and the six-shooter
15:55:44 <ev> lol
15:55:55 <ev> you heard it here, ladies and gentlemen
15:56:00 <ev> if you break trunk
15:56:01 <bdmurray> slangasek: is bug 953289 related to the one you mentioned?
15:56:02 <ubottu> Launchpad bug 953289 in unixodbc (Ubuntu) "package odbcinst1debian2 2.2.14p2-5ubuntu2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Medium,Confirmed] https://launchpad.net/bugs/953289
15:56:06 <ev> cjwatson will gun you down
15:56:10 <infinity> I'd rather be the tree deputy. No one ever shoots that guy.
15:56:16 <ev> lol
15:56:17 <slangasek> bdmurray: looking
15:56:45 <bdmurray> cjwatson: what architecture did you test?
15:56:48 <cjwatson> i386
15:57:01 <cjwatson> don't have kubuntu-precise-desktop-amd64 locally
15:57:11 <cjwatson> (would be surprised if that mattered here?)
15:57:20 <bdmurray> I used ubuntu-desktop-amd64
15:57:44 <slangasek> bdmurray: bug #953289 is an apt bug, fixed in precise but not in oneiric
15:57:45 <ubottu> Launchpad bug 953289 in unixodbc (Ubuntu) "package odbcinst1debian2 2.2.14p2-5ubuntu2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Medium,Confirmed] https://launchpad.net/bugs/953289
15:57:49 <cjwatson> ok, I do have that
15:58:12 <slangasek> bdmurray: I see odbcinst:i386 being pulled in as a dep, and it should always have odbcinst
15:58:39 <cjwatson> bdmurray: and, to be clear, you could reproduce the bug there?
15:59:19 <bdmurray> cjwatson: yes apt-get update printed errors and using apt-cdrom failed too
15:59:42 <cjwatson> bdmurray: hm, yes
15:59:50 <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:05 * infinity looks at the clock.
16:00:42 <bdmurray> cjwatson: I was using the apt-cdrom comand from 41apt-cdrom
16:01:04 <cjwatson> bdmurray: oho, it's the *i386* entries on amd64, now I understand
16:01:38 <infinity> Oh, some confusion about how multiarch should or shouldn't work WRT apt-cdrom?
16:01:43 <cjwatson> running apt-cdrom is more likely to confuse than help, I think
16:01:54 <slangasek> cjwatson: can I assign the bug to you for follow-through?
16:02:04 <cjwatson> infinity: there's some care to try to make i386 index files available on the live CD, yes
16:02:11 <cjwatson> slangasek: yep
16:02:20 <slangasek> done
16:02:22 <slangasek> bdmurray: any others?
16:02:40 <cjwatson> looks to me like I just forgot to do it for restricted
16:02:44 <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:11 <cjwatson> infinity: true, there's something odd there
16:03:14 <bdmurray> bug 946663 - but I haven't looked into it much
16:03:15 <ubottu> Launchpad bug 946663 in ubiquity (Ubuntu) "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663
16:03:42 <slangasek> can we put that one in the hopper for the sprint?
16:04:42 * slangasek gives it a rls-mgr-p-tracking
16:04:52 <infinity> The apt-cdrom/casper one seems vaguely installer sprinty too.
16:05:05 <cjwatson> I'll fix that today, I think
16:05:10 <infinity> Or that. :P
16:05:25 * cjwatson isn't planning to slow down to leave more for the installer sprint, sorry :)
16:05:29 <cjwatson> running out of days ...
16:05:52 <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:09 <cjwatson> well I was going to fix the obvious bug I see in the CD layout first
16:06:10 <infinity> cjwatson: Cause if so, it's probably just a casper bug that it's adding the i386 one.
16:06:21 <infinity> cjwatson: Oh, is the archive layout also not sane? :)
16:06:29 <cjwatson> yep, it's entirely missing restricted/binary-i386
16:06:40 <slangasek> [TOPIC] AOB
16:06:50 <slangasek> anything else, or shall we adjourn? :)
16:07:04 <infinity> *crickets*
16:07:48 <slangasek> #endmeeting