16:02:03 <slangasek> #startmeeting 16:02:03 <meetingology> Meeting started Wed Feb 6 16:02:03 2013 UTC. The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 16:02:03 <meetingology> 16:02: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 16:02:04 <jodh> o/ 16:02:12 <slangasek> [TOPIC] Lightning round 16:02:16 <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra cjwatson xnox stokachu) 16:02:19 <slangasek> barry bdmurray ogra slangasek doko cjwatson stokachu ev xnox jodh stgraber 16:02:35 <barry> win! 16:02:42 <barry> various ue sprint tasks. file debian bugs 699491 and 699498 (adding -OO to py{,3}compile). more possibly to come there. reviewed stokachu's pytz merge and eventually syncpackaged it (bug 1116418). submitted branch for bug 1112496, with updates to come. worked on py3 whoosh and reached out to debian maintainer. various upstream pypi security discussions. 16:02:46 <ubottu> Debian bug 699491 in python-defaults "pycompile: Support -OO to suppress docstrings in .pyo files" [Wishlist,Open] http://bugs.debian.org/699491 16:02:47 <ubottu> Debian bug 699498 in python3-defaults "python3-defaults: Support -OO to suppress docstrings in .pyo files" [Wishlist,Open] http://bugs.debian.org/699498 16:02:48 <ubottu> bug 1116418 in python-tz (Ubuntu) "Sync python-tz 2012c-1 (main) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/1116418 16:02:50 <ubottu> bug 1112496 in python-imaging (Ubuntu Raring) "python-imaging broken in raring" [High,Triaged] https://launchpad.net/bugs/1112496 16:02:56 <barry> * foundations-r-python33: done. 16:03:02 <barry> * foundations-r-python3-oauth: bug 1077094 marked invalid as the package is going away. bug 1077087 bug 1077089 and bug 1077092 branches in various states of review. 16:03:08 <ubottu> bug 1077094 in ubuntuone-couch "Switch from python-oauth to python-oauthlib" [Undecided,Invalid] https://launchpad.net/bugs/1077094 16:03:09 <ubottu> bug 1077087 in Ubuntu Single Sign On Client "Switch from python-oauth to python-oauthlib" [Undecided,In progress] https://launchpad.net/bugs/1077087 16:03:10 <ubottu> bug 1077089 in Ubuntu One Client "Switch from python-oauth to python-oauthlib" [Undecided,In progress] https://launchpad.net/bugs/1077089 16:03:11 <ubottu> bug 1077092 in Ubuntu One storage protocol "Switch from python-oauth to python-oauthlib" [Undecided,In progress] https://launchpad.net/bugs/1077092 16:03:18 <barry> * foundations-r-python-versions: new python-imaging (pillow) package provides py3 support, but see above bugs for backward compatibility fixes needed. in conversations about software-center and session-installer re: wtf to do about python-xapian. we may not be able to replace it :( 16:03:26 <barry> done. 16:03:43 <bdmurray> failed to recreate nexus7 bug 1092734 16:03:44 <bdmurray> worked on an upstart job to watch for an hp printer to replace update-notifier job 16:03:45 <ubottu> bug 1092734 in ubuntu-nexus7 "Software updater crashes, cannot update software graphically." [High,Fix released] https://launchpad.net/bugs/1092734 16:03:47 <bdmurray> removed unused firmware paths from uevent.c in update-notifier 16:03:49 <bdmurray> investigation into bug 1112496 (since comix doesn't work :-() 16:03:51 <ubottu> bug 1112496 in python-imaging (Ubuntu Raring) "python-imaging broken in raring" [High,Triaged] https://launchpad.net/bugs/1112496 16:03:52 <bdmurray> investigation into and testing of bug 1096022 16:03:52 <bdmurray> removed running-unity tag from the ubuntu general apport hook and upstream apport 16:03:53 <ubottu> bug 1096022 in update-manager (Ubuntu) ""E:Error, pkgProblemResolver::Resolve generated breaks" during lucid->precise universe upgrade of amd64" [Medium,Triaged] https://launchpad.net/bugs/1096022 16:03:55 <bdmurray> verified P SRU for bug 984276 16:03:56 <ubottu> bug 984276 in casper (Ubuntu Quantal) "installing casper on a non live system causes update-initramfs to fail" [High,Fix released] https://launchpad.net/bugs/984276 16:03:57 <bdmurray> bug triage of update-manager bugs with ubuntu-release-upgrade-core symptom 16:04:03 <bdmurray> improved the speed at which the user parameter works at errors 16:04:03 <bdmurray> resovled an issue on errors where + in package names and versions wasn't being encoded for using in a url 16:04:06 <bdmurray> worked on bucketsystems column family code 16:04:09 <bdmurray> created a new canonistack environment for errors since my previous one had died 16:04:13 <bdmurray> tested and modified bucketsystems column family code in canonistack 16:04:29 <bdmurray> blueprint wise I am working on foundations-r-phased-updates 16:04:45 <bdmurray> ✔ done 16:04:57 <ogra_> done: 16:04:57 <ogra_> * various nx7 bugfixes 16:04:57 <ogra_> * worked with kernel team and diwic to make sound work on boot on the nx7 16:04:57 <ogra_> * worked with kernel team to quieten the massive dmesg noise the interactive governor causes 16:04:57 <ogra_> * held UDW talk about image build infrastructure (will start a wikipage with the notes as base for proper build system documentation)# 16:04:59 <ogra_> * hunting down livefs breakage (again) 16:05:01 <ogra_> todo: 16:05:03 <ogra_> * port nx7 images to xz compression 16:05:05 <ogra_> * discuss livefs builder situation with infinity (carried over from last week, blocked on builder) 16:05:07 <ogra_> * fix plymouth vs console-setup racing somehow 16:05:16 <ogra_> done 16:05:51 <slangasek> barry: not able to replace python-xapian - hmm, have new requirements emerged, or are the alternatives proving to be inadequate? 16:06:47 <slangasek> bdmurray: planning to upload that new update-notifier upstart job soon? 16:06:53 <barry> slangasek: probably a conversation to have a bit later ;) 16:07:15 <slangasek> xnox: speaking of which, is usb-creator getting an upload with the fixed job that's in bzr? 16:07:26 <infinity> ogra_: It's been pointed out that, if you plan to use xz, depending on pxz and using that might make things slightly less painful. 16:07:27 <xnox> slangasek: yes. today. 16:07:32 <slangasek> xnox: yay :) 16:07:53 <ogra_> infinity, like ... being able to use it on the panda itself ? 16:08:03 <bdmurray> slangasek: well, I thought it should really go in hplip and haven't heard from til, additionally waiting for the user session work seems fine. 16:08:12 <infinity> ogra_: Yeah. It'll still be slower than gzip, but potentially acceptably so. 16:08:21 <ogra_> infinity, what holds me back from the switch is that i have to re-work so much stuff for it on both sides if i want nusakan to do xz 16:08:22 <slangasek> bdmurray: ah, ok 16:08:37 <ogra_> infinity, great, i'll try it then 16:08:45 <infinity> ogra_: Easy enough to take your rootfs tarball and do some local testing on a Panda. 16:08:56 <ogra_> yep 16:08:58 <infinity> ogra_: See if you can find a sweet spot. 16:09:08 <ogra_> after i fixed the installer from being completely unusable 16:09:19 <slangasek> ogra_: hunting down livefs breakage> are things currently broken, or currently working? 16:09:25 * ogra_ notes cjwatson isnt iun -desktop 16:09:38 <ogra_> slangasek, not working since we dropped a tar option 16:09:47 <ogra_> i just heard about it now 16:09:50 <slangasek> ogra_: hmm. eta for fix? 16:10:18 <ogra_> well, worst case i can roll that back immediately and we lose some memory gains cjwatson introduced 16:10:20 <infinity> ogra_: Err, wait. What? The dropping of the tar option from the installer? 16:10:33 <xnox> ac100-tarball-installer that is 16:10:36 <infinity> ogra_: How did that "break" the livefs? 16:10:37 <ogra_> infinity, droppiing of -m seems to make tar crazy 16:11:01 <slangasek> * systemd packaging: slow progress 16:11:01 <slangasek> * ovmf packaging nearly done; edk2 is clearly not structured with distributions in mind 16:11:04 <slangasek> * reviewing UbuntuKylin package submissions; will mail the TB to ask this to be an official flavor as soon as the core set is accepted 16:11:05 <ogra_> i havent digged deeper yet (or seen it myself)... i know about it since the meeting started :P 16:11:07 <slangasek> (done) 16:11:12 <infinity> ogra_: Is there a bug or any sort of analysis? 16:11:14 <xnox> well it worked without -m, but not "without -m and adding --warning=no-timestamp" or so the report says. 16:11:24 <ogra_> infinity, only chat in #ubuntu-desktop yet 16:13:13 <slangasek> doko: your turn 16:13:32 <doko> - fix ftbfs for older gcc releases (changed kernel headers, missing struct siginfo) 16:13:32 <doko> - llvm/clang updates 16:13:32 <doko> - upload pillow for python3 16:13:32 <doko> - openjdk security update 16:13:33 <doko> - FOSDEM 16:13:35 <doko> (done) 16:13:44 <doko> will follow-up on FOSDEM later 16:14:08 <ogra_> slangasek, oh, the "hunting down livefs breakage" from my report was supposed to be "hunting down livefs builder breakage" its unrelated to the current issue 16:14:27 <ogra_> (was just a coincident that you asked while i was told its broken :) ) 16:15:31 <slangasek> ah, cjwatson is off this afternoon, so stokachu: 16:15:40 <stokachu> ok 16:15:41 <slangasek> ogra_: hmm! 16:15:58 <stokachu> Followed up bug 1052038, awaits verification 16:16:00 <ubottu> bug 1052038 in eCryptfs "ecryptfs_fnek_sig missing when login at the same time on cron session close" [Medium,In progress] https://launchpad.net/bugs/1052038 16:16:00 <stokachu> Need a little more information on bug 923876 if we are planning on applying this to precise and quantal? Or whats the overall consensus on removing old kernels on a system during upgrades? 16:16:02 <ubottu> bug 923876 in apt (Ubuntu) "FR: Limit and clean-up kernel images and headers automatically in LTS" [Wishlist,Fix released] https://launchpad.net/bugs/923876 16:16:02 <stokachu> Did my first sync package request though im not sure how to tell if I got credit for the request or not other than looking at the bug itself. 16:16:04 <stokachu> (done) 16:16:34 <ogra_> slangasek, the builder was off for two days again this week ... thanks to elmo and infinity its back in business though 16:17:12 <xnox> stokachu: https://launchpad.net/~adam-stokes/+synchronised-packages 16:17:13 <ogra_> (it seems to always die on saturdays ... probably going out to party on weekends or so ) 16:17:26 <stokachu> xnox: ah ok sweet 16:17:30 <infinity> ogra_: It's probably just cause it can't count: http://sourceware.org/ml/glibc-cvs/2013-q1/msg00115.html 16:17:38 <ubottu> sourceware.org bug 2013 in libc "memccpy() gives inconsistent results on mmapped files" [Normal,Resolved: fixed] 16:17:46 <ogra_> oha 16:17:57 <ogra_> "Fix the value of TWO" 16:18:01 <stokachu> xnox: there we go :D 16:18:06 <ogra_> it couls just count one by one then :P 16:18:12 <ogra_> *could 16:18:54 <stokachu> re: apt removing older kernels is starting to make its way through internally so any thoughts on that would be appreciated 16:19:50 <infinity> stokachu: Oh, crap. So, yeah. I was meant to backport the apt stuff last week, and got distracted by other work. 16:20:00 <infinity> stokachu: I can still do that today, and maybe Colin will accept it. 16:20:05 <ev> - Feedback to Martin's code review of the grouped reports branch of apport. 16:20:05 <ev> This, if you don't recall, is for showing system internal errors as part of 16:20:05 <ev> the next regular application error. 16:20:05 <ev> - Code review for Brian. 16:20:05 <ev> - Wrote a tool to bootstrap the postgres database for local copies of Errors. 16:20:05 <ev> - Taught the prodstack-prep branches to talk to Swift natively when running on 16:20:06 <ev> canonistack/prodstack. 16:20:13 <ev> - Added the bulk of the Canonical engineering teams to the ACL for stacktrace 16:20:14 <ev> access on errors.ubuntu.com. Added code to Errors and the prodstack charms to 16:20:14 <ev> manage further additions to the ACL with minimal code changes. 16:20:14 <ev> - Big improvements to the average errors per calendar day graph over the 16:20:14 <ev> weekend. The text for the milestones and dates finally all fits. We now also 16:20:15 <ev> set the domain to (0, 0.4) so the difference between 12.04 and 12.10 should 16:20:22 <ev> be much more discernable. There's a few more improvements to be made that 16:20:23 <ev> I'll fit in while other work compiles or in the evening. I've also cleaned up 16:20:23 <ev> the call stack representation in the most common problems table. 16:20:23 <ev> - More fixes to whoopsie. Trying to get a new build out, but the tests are 16:20:29 <ev> failing only in sbuild due to leaks detected by valgrind. Fixed one already, 16:20:29 <ev> so this new memcheck test addition is already proving useful. 16:20:29 <ev> - If we can move the connectivity check and inotify watch into upstart, we 16:20:29 <ev> save about 0.8 MB of memory in whoopsie (though admittedly whoopsie no 16:20:34 <ev> longer runs all the time and its memory usage becomes less important). 16:20:35 <ev> - Not pulling in CURL takes us down to running in 200K, but we kind of need 16:20:35 <ev> that :). I suspect its the SSL stuff taking up the lion's share. 16:20:40 <ev> - More fixes to the prodstack charms. JuanJo is making good headway on getting 16:20:40 <ev> these deployed to stagingstack. 16:20:40 <ev> - Trying to build the universe to get a recent version of python-swiftclient 16:20:40 <ev> working in precise. 16:20:43 <ev> (done) 16:20:59 <stokachu> infinity: ok no worries i was just pinged internally about this yesterday so its not really heating up yet and your confirmation of it is good enough 16:21:01 <stokachu> thanks 16:21:24 <xnox> * Short week due to Fosdem Fri-Mon 16:21:24 <xnox> - loads of people met and conversations held 16:21:24 <xnox> - everyone is talking about aarch64 16:21:24 <xnox> - everyone is waiting for aarch64 hw 16:21:24 <xnox> - interesting talks on init systems & [e]udev 16:21:25 <xnox> - keysigning... 16:21:27 <xnox> . 16:21:29 <xnox> * Last week, poked pyo optimisation with barry a little. 16:21:31 <xnox> I want to run one last test (i think i didn't have everything 16:21:33 <xnox> without docstrings), but it looks likes on currently idle python 16:21:35 <xnox> processes there isn't much ram savings. 16:21:37 <xnox> * Also gave a talk on making/fixing packages to cross-build. Need to 16:21:41 <xnox> convert to blog post / packaging guide section. 16:21:43 <xnox> . 16:21:45 <xnox> * Precise: 16:21:45 <stokachu> infinity: will this be for quantal and precise? 16:21:47 <xnox> Uploaded SRU for 2 clustered LVM issues. Not critical for 12.04.2 as 16:21:49 <xnox> clvm is not on the server cds. bug #833368 and bug #988881 . 16:21:51 <xnox> . 16:21:52 <ubottu> bug 833368 in lvm2 (Ubuntu Precise) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [High,In progress] https://launchpad.net/bugs/833368 16:21:53 <xnox> * foundations-r-arm-usb-creator-fastboot-support: 16:21:53 <ubottu> bug 988881 in lvm2 (Ubuntu Precise) "/etc/init.d/clvm status exitcode always 0" [Medium,In progress] https://launchpad.net/bugs/988881 16:21:55 <xnox> udisks2 backend created a few sticks now. Porting/Testing last 16:21:57 <xnox> pieces in the -helper and then we can drop udisks from CD. 16:21:59 <xnox> . 16:22:01 <xnox> * foundations-r-software-raid 16:22:03 <xnox> mdadm initial merge ready, should upload by the end of the week. 16:22:05 <xnox> (done) 16:22:11 <infinity> stokachu: That's the general plan. 16:22:15 <jodh> * blueprints 16:22:15 <stokachu> ok sounds good 16:22:15 <jodh> - foundations-r-upstart-user-session-enhancements: 16:22:15 <jodh> - Merged lp:~jamesodhunt/upstart/setenv+getenv. 16:22:15 <jodh> - Finished and raised MP for lp:~jamesodhunt/upstart/event-prefixes. 16:22:18 <jodh> - Wrote and raised MP on 16:22:20 <stokachu> ill relay that information 16:22:22 <jodh> lp:~jamesodhunt/upstart/remove-initctl-job+instance-options 16:22:25 <jodh> - Working on upstart shutdown. 16:22:28 <jodh> - foundations-r-upstart-roadmap: no progress 16:22:31 <jodh> - foundations-r-arm-ubiquity: no progress 16:22:35 <jodh> * other: 16:22:38 <jodh> - FOSDEM 2013 (away Fri-Mon) 16:22:41 <jodh> - MP for restarting Upstart on libjson0 upgrade 16:22:44 <jodh> https://code.launchpad.net/~jamesodhunt/ubuntu/raring/json-c/restart-upstart/+merge/146868 16:22:47 <jodh> Ꭸ 16:22:48 <jodh> 16:23:02 <slangasek> bah, ok, this is the second time since upgrading this machine to raring that the desktop has completely locked up for minutes at a time... not even the cursor moves 16:23:07 <slangasek> anybody else seeing this? 16:23:24 <stgraber> Feature work: 16:23:25 <stgraber> - Upstart (BLUEPRINT: foundations-r-upstart-user-session-enhancements) 16:23:25 <stgraber> - No progress done last week, planning on testing it this week. 16:23:25 <stgraber> - Container (BLUEPRINT: servercloud-r-lxc) 16:23:25 <stgraber> - libseccomp was promoted to main 16:23:27 <stgraber> - Worked on a fix for bug 1113821 16:23:29 <ubottu> bug 1113821 in libvirt (Ubuntu Raring) "libvirt-bin deletes /etc/dnsmasq.d/libvirt-bin on upgrade" [Medium,Triaged] https://launchpad.net/bugs/1113821 16:23:29 <stgraber> - Code reviews. 16:23:32 <stgraber> - Preparing 0.9~alpha3 to be released next week. 16:23:34 <stgraber> - Discussed plan for container/security/lxc micro-conference at LPC2013 16:23:35 <barry> slangasek: nope. what h/w do you have? 16:23:37 <stgraber> - Networking (BLUEPRINT: foundations-r-networking) 16:23:40 <stgraber> - Still waiting on test results for the infiniband support, no other progress there. 16:23:43 <stgraber> Other work: 16:23:45 <stgraber> - Networking 16:23:48 <stgraber> - Spent quite a bit of time getting Ofono to work with NetworkManager, slowly getting there. 16:23:51 <stgraber> (glib + gobject + dbus in NM can be the source of rather bad headaches...) 16:23:54 <stgraber> - QATracker 16:23:55 <slangasek> stokachu: on the apt kernel autoremoval, I thought we already did backport that to precise+quantal, no? 16:23:56 <stgraber> - Helped setup some other internal instances of the tracker. 16:23:59 <stgraber> - Meetings/Talks 16:24:01 <stgraber> - Had an Ubuntu Development Hangout yesterday 16:24:04 <stgraber> - Will have an LXC IRC meeting tomorrow to present the user namespace work and discuss some of the next steps. 16:24:07 <stgraber> TODO: 16:24:09 <stgraber> - Continue the ofono/NM work. 16:24:12 <stgraber> - Try to finish any LXC feature work for this cycle (1 item left). 16:24:14 <stgraber> - Prepare some upstart user session debs with all our patches and the initial Xsession scripts and upstart jobs. 16:24:17 <stgraber> (DONE) 16:25:13 <stokachu> slangasek: ill double check but tmk it wasn't 16:25:24 <stgraber> if it was, it's not working ;) 16:25:42 * stgraber had to manually wipe a few kernels on a dozen machine over the weekend to clear some space in /boot 16:26:15 * barry too 16:26:25 <bdmurray> heh, me too! 16:26:29 <bdmurray> just one machine though 16:28:25 * xnox currently has 9 kernels on my machine in raring.... i thought i should have less. 16:28:38 <slangasek> barry: hw> standard intel mobile graphics, I forget the model 16:29:02 * ogra_ has 12 on precise 16:29:42 <slangasek> heh, ok - and infinity 'fessed up that it's still on his todo, so 16:30:07 * slangasek gets to the bottom of scrollback finally 16:30:10 <stgraber> slangasek: if that's your x201, then it's first gen i7 graphics (Arrandale chipset with Ironlake graphics, product id 0046) 16:30:20 <slangasek> yeah, that ;) 16:30:40 <infinity> xnox: Before you go manually doing anything to those kernels, talk to me out of band. 16:30:41 <slangasek> so there seem to be two entangled problems here 16:31:08 <xnox> infinity: ack. My install is not typical by any means, so it could be of my wrong doing. 16:31:11 <barry> slangasek: i've got a radeon 16:31:15 <slangasek> one is that firefox is helpfully using 100% of a CPU; the other is that X is using 100% of a CPU and not responding interactively 16:31:28 <slangasek> I guess I should file a critical bug, when I can get back to the desktop 16:31:30 <xnox> stgraber: do you want to help out specing a machine for me?! =) 16:32:17 <ogra_> you should definitely get more cores then ... one per app or so 16:32:18 <slangasek> [TOPIC] work item 16:32:20 <slangasek> [TOPIC] work items 16:32:38 <slangasek> ogra_: X already has a core to itself, it's not doing anything *useful* with it :P 16:32:50 <ogra_> heh 16:33:12 <stgraber> xnox: hehe, I just happen to have used a pretty much identical laptop to slangasek's for the past two years and had some X problems in the past ;) 16:33:15 <slangasek> so I was going to pull up some numbers to see how we're all doing individually wrt the burndown trend line 16:33:33 <slangasek> but with my laptop being coy, those numbers are currently not at my fingertips 16:33:35 <stgraber> xnox: now I'm on a x230 with a different set of problem (mostly caused by me only using displayport displays which apparently nobody does...) 16:34:01 <slangasek> instead, I'll just say that you should all be checking your personal status.ubuntu.com page and making sure that you are below the trendline, as of *today* 16:34:25 <slangasek> if you aren't, that doesn't mean you need to work overtime, it means you need to talk to me to figure out what we need to postpone or move around on the team 16:34:55 <slangasek> the team's burndown is above the line, and realistically, we're going to be seeing demands on our time for work not shown on that chart (i.e., work to support the mobile effort) 16:35:23 <slangasek> so we need to get our priorities squared away wrt the stuff from UDS, so that people know what we are actually delivering this cycl 16:35:26 <slangasek> e 16:35:35 <slangasek> any questions? 16:35:50 <stgraber> slangasek: not sure if that also impacts the team's trendline, but I have 10 Edubuntu work items in my personal chart which if ignored makes me below the trendline 16:35:58 <barry> slangasek: do in progress count? :) 16:36:27 <slangasek> also, note that even with everyone on the team down below the trendline, we'll be above the trendline for the team as a whole because of workitems on our blueprints that are assigned to people not on the team 16:36:56 <doko> tex-common at version 3.15? that looks wrong ... 16:36:57 <ev> should we add workitems for things that have come up? For example, I wasn't expecting to do all this prodstack stuff. 16:37:02 <slangasek> so if you're the assignee for a blueprint that has external workitems, please be sure to check with those folks on how they're doing and if they'll still deliver this cycle 16:37:22 <slangasek> ev: no, burndown charts shouldn't be an exercise in paperwork to make us look productive :) 16:37:32 <slangasek> barry: no ;) 16:37:33 <infinity> doko: Wrong, how? 16:37:54 * xnox ponders what to do with Low and Undefined priority specs which was mostly community/nice-to-haves 16:37:56 <slangasek> stgraber: it does impact the team's trendline, but I'll mentally subtract 16:38:02 <doko> doesn't approach Pi anymore 16:38:11 <infinity> Hahaha. 16:38:16 <slangasek> stgraber: so don't worry about faking up the state just to make the trendline happy 16:38:30 <xnox> infinity: it's not hahaha, but a real problem. it should never been 3.15. 16:38:35 <stgraber> slangasek: good ;) 16:38:36 <infinity> doko: There's a 4.xx in experimental, if you really want to be sad about the versions inflating. 16:38:51 <xnox> /o\ did TeX community go crazy?! 16:39:11 <slangasek> xnox: realistically, they should probably be postponed; if you run out of todo work items early, you can always rescue them from the postponed pile 16:39:16 <slangasek> any other qs? 16:40:02 <slangasek> [TOPIC] Bugs 16:40:12 <slangasek> bdmurray: what news? 16:40:43 <bdmurray> I believe this is our top error at the moment 16:40:48 <bdmurray> https://errors.ubuntu.com/bucket/?id=/usr/bin/apturl-gtk:AttributeError:parseArgs:parse:%3Cmodule%3E:main:parseArgs 16:41:48 <stgraber> oh nice, .decode() on a python3 string, that won't quite work ;) 16:42:03 <xnox> bdmurray: so we should check latest apt-urls posted on OMGubuntu to find the culprit =) 16:42:27 <barry> ouch ;) 16:42:46 <xnox> ev: we don't have server side hooks yet to query what sting is failing?! 16:43:04 <bdmurray> 16:43:06 <bdmurray> /usr/bin/python3 /usr/bin/apturl-gtk /home/whoever/Downloads/MediaPlayerClassic_RocketFuelInstaller (1).exe 16:43:24 <ev> xnox: I am but one man, busy getting everything ready for the cloud. 16:43:25 <bdmurray> I guess we could look at the proccmdlines? 16:44:01 <barry> is the str.decode() bug filed? 16:44:08 <xnox> ev: True. prodstack is a lot of "prod" in it. 16:44:15 <bdmurray> barry: no 16:44:16 <ev> :) 16:44:52 <bdmurray> oh, maybe its because apturl is being used with local files? 16:45:00 <slangasek> oh this is special 16:45:05 <slangasek> killall -9 firefox, and it keeps going 16:45:34 <ogra_> lovely 16:45:43 <barry> slangasek: i saw a lot of ineffective kill -9s on the nexus 16:45:46 <ogra_> sudo harder :) 16:45:50 <xnox> bdmurray: not quite. it looks like some browser extension went crazy cause all files are (a) local (b) in download or .cache locations 16:45:52 <slangasek> barry: ! 16:45:55 <ogra_> barry, bug # ? 16:45:56 <ogra_> :) 16:46:05 <slangasek> sounds like we need to file a critical bug against the kernel for that, too 16:46:18 <ogra_> nx7 is a different kernel though 16:46:45 <xnox> bdmurray: but apt-url should handle that fine, but it won't help if browser has now defaulted to open everything with apt-url instead of other mime-handlers. 16:46:49 <barry> yeah, you know which kernel i'm talkin' 'bout. i wasn't shaving the yak that day though 16:46:56 <ogra_> (which doesnt say much, might be present since before the nx7 kernel, who knows) 16:46:59 <stgraber> well, kill -9 can be ineffective if the process is stuck in I/O wait (D state) 16:47:27 <stgraber> now the source of the I/O wait is usually the bug (and in some cases it's a kernel bug) 16:47:36 <bdmurray> xnox: you seem to be knowledgeable about this and in a good position to look at... 16:47:41 <slangasek> stgraber: it's not in I/O wait, it's actively consuming my CPU 16:48:06 <xnox> bdmurray: ok. I'll chat with -desktop folks and try to investigate it. 16:48:09 <stgraber> slangasek: hmm, ok, that's really special then ;) 16:48:15 <slangasek> xnox: assign the bug to yourself? 16:48:29 <slangasek> (er, if there is a bug yet) 16:49:13 <slangasek> bdmurray: any other bugs/crashes you're worried about? 16:49:22 <bdmurray> ev: oh maybe there should a create bug link on the bucket page 16:49:36 <ev> bdmurray: yes, definitely 16:49:41 <bdmurray> ev: because you'd have to go to ?package=apturl and then find the right bucket 16:50:13 <bdmurray> slangasek: the rls r tracking bugs are looking a bit long 16:50:22 <bdmurray> there are 3 critical ones 16:50:28 <bdmurray> bug 1066480 16:50:30 <ubottu> bug 1066480 in ubiquity (Ubuntu Raring) "Installer doesn't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480 16:50:35 <bdmurray> bug 1013798 16:50:37 <ubottu> bug 1013798 in libgcrypt11 (Ubuntu Raring) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/1013798 16:50:46 <slangasek> bdmurray: sorry, can you pass the link to the report too? 16:50:53 <bdmurray> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html 16:51:04 <bdmurray> and bug 1084063 16:51:06 <ubottu> bug 1084063 in ubuntu-defaults-nexus7 (Ubuntu Raring) "plymouth in raring causes system hardlock if console_setup is not run in the initramfs on nexus7 prior to starting plymouthd" [Critical,In progress] https://launchpad.net/bugs/1084063 16:53:10 <ogra_> yeah, thats a bad one, i think colin took a look but we didnt talk about it yet 16:53:17 <slangasek> 1084063 is already on ogra's todo list, AIUI 16:53:22 <ogra_> yeah 16:53:25 <slangasek> stokachu: any luck with bug #1013798? 16:53:27 <ubottu> bug 1013798 in libgcrypt11 (Ubuntu Raring) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/1013798 16:53:36 <slangasek> xnox: can you take bug #1066480? 16:53:37 <ubottu> bug 1066480 in ubiquity (Ubuntu Raring) "Installer doesn't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480 16:53:43 <xnox> bug 1066480 is on me. but can be worked on post ff. 16:54:13 <xnox> The solution is to correctly try and call existing partman-crypto api call that colin pointed out to me previously. 16:54:17 * slangasek assigns 16:55:12 <bdmurray> I looked at some of the ubiquity ones yesterday and also noticed that bug 1080701 is still getting regular metoos 16:55:14 <ubottu> bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/1080701 16:55:49 <slangasek> already assigned to xnox - are you missing any information to be able to work on that one? 16:56:07 <xnox> bdmurray: there are two hang fixes in os-prober I uploaded. Which needs to be uploaded as part of ubiquity. 16:56:34 <xnox> it is random for me and I cannot reliable reproduce it with debugging on to see what hangs. 16:57:34 <slangasek> [TOPIC] AOB 16:57:46 <slangasek> anything else to discuss? 16:58:46 <slangasek> #endmeeting