15:03 #startmeeting 15:03 Meeting started Thu Sep 10 15:03:46 2015 UTC. The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 15:03 15:03 Available commands: action commands idea info link nick 15:03 oh, did MacSlow join foudations ? 15:03 [TOPIC] Lightning round 15:03 $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx) 15:04 bdmurray infinity slangasek cyphermox barry caribou doko tdaitx sil2100 robru pitti 15:04 nvestigation into retracer issues and queue sizes 15:04 modifed the retracers to not try to get the core for a crash that has already been retraced 15:04 updated retracer.py not to log the swift token as it is noisy in the logs 15:04 wrote code to analyze successfully retraced armhf OOPSes to find buckets w/o bugs (to then manually open bugs) 15:04 worked on apport bug 1490030 (apport hook for shim-signed) 15:04 bug 1490030 in shim-signed (Ubuntu) "shim-signed should include an apport hook applying to shim and shim-signed source packages" [Undecided,New] https://launchpad.net/bugs/1490030 15:04 modified merges.ubuntu.com reports not to show blacklisted packages 15:04 ✔ done 15:05 - Kernel SRU work 15:05 - Meetings, interviews, meetings, and more meetings 15:05 - Championed PPA deletion in the LP meeting for robru, should get that this cycle 15:05 - Fleshed out s390x in Launchpad plans in the same meeting 15:05 - Finally landed mirror fix to avoid Translations hash sum mismatches 15:05 - More work on glibc in both Debian and Ubuntu 15:05 - Bootstrapping s390x 15:05 (done) 15:05 infinity: yay! re: mirror fix 15:06 Is mumble explodey for anyone else, or is it just me? 15:06 infinity: seems ok 15:07 Weird. It connects me, shows no channels, and eventually kicks me out again. 15:07 * short week, Labor Day holiday 15:07 * interviewing continues for the open generalist role 15:07 * we are now also hiring for a dedicated zSeries engineer: https://ldd.tbe.taleo.net/ldd01/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=1023 15:07 * most of the week spent either interviewing or in planning meetings for s390x 15:07 * also some discussions about golang for its in-progress MIR 15:07 (done) 15:07 * spent some time looking at component-mismatches, which is quite lengthy right now - particularly for packages needing demotion, seems this is a lot harder to keep clean ever since -proposed happened 15:08 I always start with component-mismatches-proposed 15:08 cyphermox: 15:08 - Monday was a national holiday. 15:08 - upload ubiquity 2.21.28 15:08 - fix NM bugs blocking autopkgtests 15:08 - skiboot SRU to vivid 15:08 - sponsored multipath bug fix for LP: #1489379 (libchecktur w/ -fexceptions) 15:08 - some debugging netcfg for setting the hostname in preseeded installs 15:08 Launchpad bug 1489379 in multipath-tools (Ubuntu) "LTE: ISST:leeklp4 no mpath choices for install ubuntu 15.10" [High,Fix released] https://launchpad.net/bugs/1489379 15:08 - upload console-setup update to get dracut installable. 15:08 - reviewed/sponsored libreoffice, libreoffice-l10n, writer2latex, nlpsolver. 15:08 - setting up my environment for fwupdate testing 15:09 - blocked on firmware availability. 15:09 (done) 15:09 short week due to usa holiday 15:09 lots more py35 transition work. down to 9 legit ftbfs in primary flavor seeds (an additional 4-5 ftbfs in all other seeds). see email to ubuntu-devel@ for details (several fixes uploaded since then). bugs filed on all packages. 15:09 python-netaddr 0.17.7-1; LP: #1492359; python-testtools 1.4.0-0ubuntu2; LP: #1352900 15:09 Launchpad bug 1492359 in genshi (Ubuntu) "genshi FTBFS with Python 3.5 in Wily" [High,Fix released] https://launchpad.net/bugs/1492359 15:09 Launchpad bug 1352900 in pypy (Ubuntu) "[MIR] pypy" [Undecided,Fix released] https://launchpad.net/bugs/1352900 15:09 interviews, etc. 15:09 --done-- 15:09 * infinity gives up on mumble. 15:10 caribou: 15:10 Bugfix: 15:10 - lucid -> precise -> trusty upgrade issue 15:11 * Unbootable system after upgrade (LP: #1491894) 15:11 Launchpad bug 1491894 in grub2 (Ubuntu Trusty) "lucid to precise to trusty upgrade may leave system unbootable" [High,In progress] https://launchpad.net/bugs/1491894 15:11 Able to reproduce, working on a fix 15:11 ☑ Done 15:11 - looking at the ruby mess. ruby2.2 was added as supported this cycle, but nobody rebuilt packages. done that. 15:11 - made ruby-rspec build by dropping most of the test dependencies (universe) 15:11 - ruby fixing, syncing, cursing ... 15:11 - python3.5 rc3 15:11 - openjdk-7, openjdk-8, openjdk-9 updates 15:11 - MIRs, ruby package removals, syncs, merges, fix ftbfs's 15:11 - s390x cross toolchains 15:11 - s390x meeting 15:11 - some more GCC triggered transitions nbs is clean again, update_output.txt as well. 15:11 - started to re-enable pypy-* packages. 15:11 (done) 15:11 * Short week, holiday on Monday (2015-09-07) 15:11 Current/Past 15:11 - Investigated a few 15:11 - Provided pull requests for JRuby (https://github.com/jruby/jruby/pull/3309 and https://github.com/jruby/jruby/pull/3310) to fix mspec failure (LP: #1491526) 15:11 - Refreshed patch to include dep3 info (Debian #794190) 15:11 - Found regression on JDK7 TLS 1.2 backports, investigating cause (LP: #1482924) 15:11 Next steps 15:11 Launchpad bug 1491526 in jruby (Ubuntu) "jruby FTBFS when running mspec tests" [Undecided,New] https://launchpad.net/bugs/1491526 15:11 - Refactor JRuby 3310 pull request 15:11 - Fix JDK TLS 1.2 regression 15:12 - Guarantee that local JCK 7 tests are running fine for trusty, then move those to canonistack 15:12 - Setup and use umt schroots, move them to canonistack 15:12 Debian bug 794190 in quota "quota FTBFS on wily proposed due to wrong LDFLAGS usage" [Important,Open] http://bugs.debian.org/794190 15:12 Waiting/On hold 15:12 Launchpad bug 1482924 in openjdk-7 (Ubuntu) "Regressions due to USN-2696-1" [Undecided,New] https://launchpad.net/bugs/1482924 15:12 - trust-store (universe) blocks pulseaudio (main); found MIR request but I'm unable to change status, left a comment but no answer so far (LP: #1338587) 15:12 Launchpad bug 1338587 in trust-store (Ubuntu) "[MIR] trust-store" [Undecided,Fix released] https://launchpad.net/bugs/1338587 15:12 (done) 15:12 (short week with labour day) 15:12 lp:cupstream2distro 15:12 - set the request creator's name in debian/changelog rather than using ci train bot name. 15:12 - call checkUpload to enforce correct package upload permissions, ending honor system that used to be in place 15:12 - eliminated the need to ever reconfigure a silo by sourcing info directly from bileto (this was a massive architectural shift that took a bunch of work which is why this list is really short) (also this isn't in production yet) 15:12 (done) 15:12 sil2100 is on vac 15:12 systemd: 15:12 - integrate networkd with the distro (resolvconf, if-*.d hooks) and document how to enable it (https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown), announce to u-devel@ 15:12 - fix various regressions in trunk spotted by our daily(ish) upstream package builds, provide 226 in PPA for testing 15:12 autopkgtest: 15:12 - Add fallback for dealing with build profiles with trusty's libdpkg-perl, to fix linux tests 15:12 - Fix armhf/ppc64el autopkgtest runners to pull from ftpmaster.internal 15:12 - Discuss kernel version reporting in tests with apw 15:13 misc: 15:13 - Build new 15.04 langpacks with libusermetrics (#1484882) 15:13 - Investigate NetworkManager test regressions; make some adjustments, file #1492126 and #1492168 for root causes 15:13 - Some travel preps for the snappy sprint 15:13 - usual daily -proposed cleanup/unblocking/investigations 15:13 [END] 15:13 pitti: love the new summary at the end of adt-run 15:13 barry: me too! nice idea 15:14 barry: one of these 5 s improvements :) 15:14 pitti: :) 15:15 tdaitx: "unable to change status" - so we need to get you bug privileges still? 15:17 slangasek, possibly, I was not sure if I should have them already or just after I got in as a core dev 15:18 tdaitx: there's a separate process for getting bug triaging privileges that doesn't require you to be an Ubuntu dev; bdmurray probably has the link handy :) 15:18 I don't see why that MIR would need its status changed? 15:18 tdaitx: though for MIR bugs, note that the bug is a process bug so you probably don't need to change its state anyway, the MIR team does this 15:19 tdaitx: https://wiki.ubuntu.com/UbuntuBugControl 15:19 "Requirement 4 can be waived if you are an upstream developer or bug triager or if a Ubuntu developer vouches for you (your triaging ability)." 15:19 any other questions over status? 15:21 [TOPIC] AOB 15:21 pitti, bdmurray: there's a bug escalated by the phone team about apport that I'd like to get your input on 15:21 bug #1278780 15:21 bug 1278780 in apport (Ubuntu) "apport takes too long to write crash report, appears to lock up phone" [High,Triaged] https://launchpad.net/bugs/1278780 15:21 slangasek: I've seen it; you summarized it well 15:21 ok 15:22 apart from the nice level tweakage I'm afraid I don't have any othe magic sauce to pour over this, though 15:22 tdaitx: For MIRs of this nature specifically, if something has been in main in the past and fell out again (because it was unseeded or nothing depended on it anymore), just poke an archive admin with a pointer to the old bug/status, and we can re-promote it (done now). 15:22 I think the short term plan is that crash reporting will be disabled on the phone by default until they can give us something more fine-grained for blacklisting 15:22 high nice level is better for background processes and worse for foreground, so maybe we should optimize for the latter 15:23 slangasek: but TBH I doubt that it'll make a noticeable difference 15:23 it might suck a tad less, but it'd still suck 15:23 pitti: would you be ok with dropping the os.nice() call anyway, to see if it does make a difference? 15:23 slangasek: yes, I'm fine with that; I'd just not claim that this would fix the bug 15:23 tdaitx, no need to redo the MIR, it already was approved. promoted that 15:23 and am I right that when the unity system compositor is what crashes, the kernel has to dump all the mapped memory, including the graphics buffers? 15:24 bdmurray, slangasek yeah, I have that page saved, I am in the bug squad and was collecting additional triaging experience before I sent out my request to join bug control 15:24 Disabling by default seems a bit drastic to me. Given pitti's changes to apport, which has resulted in more crashes being reported, have there actually been more reports complaints re "appears to lock up phone" 15:24 slangasek: I'm less sure about that (not famiilar with the innards of core dumps), but it seems likely 15:24 bdmurray: yes, there have 15:25 bdmurray: and it's a grave issue, including potentially a regulatory one if the phone is blocked and you can't make an emergency call 15:25 on a different note, is anybody here a libunity expert (or know one)? 15:25 slangasek: alrighty 15:25 slangasek: That would certainly have been true in the old skool Xorg days with an mmapped /dev/mem, can't say how unity8/mir behave in that regard, but it seems likely. 15:26 bdmurray: I'm going to continue pressing the phone team for a fine-grained blacklist so that we can do something better than disabling it by default, but I don't think we should block on this 15:26 it looks like Laney has been working on the ability to turn on and off crash reporting 15:26 infinity, pitti: what if the system compositor had a custom SIGSEGV handler to unmap the video buffers and reraise the signal? 15:27 bdmurray: there's a toggle for it in the UI that apparently doesn't work right currently 15:27 slangasek: that would certainly be very helpful 15:27 pitti: "helpful" - but would it be sane? :) 15:27 "maybe". 15:27 slangasek: right, he's made some changes to whoopsie-preferences today see bug 1437633 15:27 bug 1437633 in Canonical System Image "Choosing not to report crashes and errors setting reverts" [Critical,In progress] https://launchpad.net/bugs/1437633 15:27 slangasek: for most processes it shouldn't take that long, supposedly not manyu programs are handling huge gfx buffers 15:27 Manipulating memory after a crash is always iffy. 15:27 slangasek: absolutely, yes 15:28 We have such features intentionally disabled in glibc because it's pretty lolz to operate on pointers that might be pointing to another universe. 15:28 slangasek: it's dramatically unlikely that a stack trace goes "through" the framebuffer, there should be no code there 15:28 slangasek: and in the end the stack trace is all that we keep anyway for a successful retrace 15:28 bdmurray: right, that's the other bug that pmcgowan mentioned 15:28 slangasek: so freeing data can only be helpful 15:28 pitti, bdmurray: so it seems at least worth suggesting this to the unity team 15:28 pitti: If the crash is in shader magic or something, it could absolutely be running rampant through video memory. 15:29 infinity: would that show on the process stack? 15:29 infinity: well, we can't dump GPU code anyway, can we/ 15:29 ? 15:29 slangasek: Hrm. Probably not, I suppose. Would just be an opaque call from libgl. Probably. 15:29 I'm a bit rusty on all of that, it's been a decade since I lived with daniels. 15:29 I mean, if we have the choice between "no bugs for unity" vs. "a few corner cases have broken stack traces", the former sounds much more desirable 15:29 err, the latter 15:29 ok, I'll suggest this then, thanks 15:30 (not that unity having no bugs wouldn't be desirable..) 15:30 (I'm not sure how much of the process's memory will actually be video buffers, but it's worth looking at) 15:30 slangasek: are you aware of the "gcore" tool? 15:30 no 15:30 pitti: We can dump GPU code, but it would be an entirely different trace, via a callback to the kms driver or libgl. 15:30 slangasek: quite handy for doing such comparisons without acutally having to crash your program 15:30 pitti: See all the Intel GPU vomit one gets in dmesg. :P 15:31 pitti: ah nice 15:31 infinity: right, I thought X (or kernel or whatever) has some special apport hooks for that 15:31 pitti: X does, yes. 15:31 slangasek: so one could do gcore / do something to trigger video memory free / gcore again / compare 15:31 pitti: Mir probably wants the same ones. 15:31 pitti: pmap might also give us the info we need for this 15:32 infinity: if the phone were using KMS, sure ;) 15:32 (yes eventually we want it for the desktop if we don't have it there already) 15:32 its probably worth noting that fixing bug 1437633 won't actually stop apport from creating crash reports 15:32 bug 1437633 in Canonical System Image "Choosing not to report crashes and errors setting reverts" [Critical,In progress] https://launchpad.net/bugs/1437633 15:33 ah because that's a setting for reporting crashes 15:33 bdmurray: thanks for catching that 15:33 bug 1389407 might be better 15:33 so really we're looking at an upstart override or something here 15:33 bug 1389407 in ubuntu-system-settings (Ubuntu RTM) "choosing not to report "app crashes and errors" leaves apport and whoopsie running" [High,Confirmed] https://launchpad.net/bugs/1389407 15:34 right 15:34 bdmurray: thanks 15:34 anything else? 15:34 slangasek: bug updated 15:36 going.... 15:36 going... 15:36 #endmeeting