[15:00] <cyphermox> o/
[15:01] <pitti> o/
[15:01] <robru> \o
[15:01] <caribou> o/
[15:02] <tdaitx> \o
[15:02] <infinity> \o/
[15:03] <barry> o>-<
[15:03]  * ogra_ watches the yoga group 
[15:03]  * slangasek waves
[15:03] <slangasek> ogra_: it's capoeira this week
[15:03] <slangasek> #startmeeting
[15:03] <meetingology> 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] <meetingology> Available commands: action commands idea info link nick
[15:03] <ogra_> oh, did MacSlow join foudations ?
[15:03] <slangasek> [TOPIC] Lightning round
[15:03] <slangasek> $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx)
[15:04] <slangasek> bdmurray infinity slangasek cyphermox barry caribou doko tdaitx sil2100 robru pitti
[15:04] <bdmurray> nvestigation into retracer issues and queue sizes
[15:04] <bdmurray> modifed the retracers to not try to get the core for a crash that has already been retraced
[15:04] <bdmurray> updated retracer.py not to log the swift token as it is noisy in the logs
[15:04] <bdmurray> wrote code to analyze successfully retraced armhf OOPSes to find buckets w/o bugs (to then manually open bugs)
[15:04] <bdmurray> worked on apport bug 1490030 (apport hook for shim-signed)
[15:04] <bdmurray> modified merges.ubuntu.com reports not to show blacklisted packages
[15:04] <bdmurray> ✔ done
[15:05] <infinity> - Kernel SRU work
[15:05] <infinity> - Meetings, interviews, meetings, and more meetings
[15:05] <infinity> - Championed PPA deletion in the LP meeting for robru, should get that this cycle
[15:05] <infinity> - Fleshed out s390x in Launchpad plans in the same meeting
[15:05] <infinity> - Finally landed mirror fix to avoid Translations hash sum mismatches
[15:05] <infinity> - More work on glibc in both Debian and Ubuntu
[15:05] <infinity> - Bootstrapping s390x
[15:05] <infinity> (done)
[15:05] <barry> infinity: yay! re: mirror fix
[15:06] <infinity> Is mumble explodey for anyone else, or is it just me?
[15:06] <barry> infinity: seems ok
[15:07] <infinity> Weird.  It connects me, shows no channels, and eventually kicks me out again.
[15:07] <slangasek>  * short week, Labor Day holiday
[15:07] <slangasek>  * interviewing continues for the open generalist role
[15:07] <slangasek>  * 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] <slangasek>  * most of the week spent either interviewing or in planning meetings for s390x
[15:07] <slangasek>  * also some discussions about golang for its in-progress MIR
[15:07] <slangasek> (done)
[15:07] <slangasek>  * 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] <doko> I always start with component-mismatches-proposed
[15:08] <slangasek> cyphermox:
[15:08] <cyphermox>  - Monday was a national holiday.
[15:08] <cyphermox>  - upload ubiquity 2.21.28
[15:08] <cyphermox>  - fix NM bugs blocking autopkgtests
[15:08] <cyphermox>  - skiboot SRU to vivid
[15:08] <cyphermox>  - sponsored multipath bug fix for LP: #1489379 (libchecktur w/ -fexceptions)
[15:08] <cyphermox>  - some debugging netcfg for setting the hostname in preseeded installs
[15:08] <cyphermox>  - upload console-setup update to get dracut installable.
[15:08] <cyphermox>  - reviewed/sponsored libreoffice, libreoffice-l10n, writer2latex, nlpsolver.
[15:08] <cyphermox>  - setting up my environment for fwupdate testing
[15:09] <cyphermox>    - blocked on firmware availability.
[15:09] <cyphermox> (done)
[15:09] <barry> short week due to usa holiday
[15:09] <barry> 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] <barry> python-netaddr 0.17.7-1; LP: #1492359; python-testtools 1.4.0-0ubuntu2; LP: #1352900
[15:09] <barry> interviews, etc.
[15:09] <barry> --done--
[15:09]  * infinity gives up on mumble.
[15:10] <slangasek> caribou:
[15:10] <caribou> Bugfix:
[15:10] <caribou>  - lucid -> precise -> trusty upgrade issue
[15:11] <caribou>    * Unbootable system after upgrade (LP: #1491894)
[15:11] <caribou>      Able to reproduce, working on a fix
[15:11] <caribou> ☑ Done
[15:11] <doko> - looking at the ruby mess. ruby2.2 was added as supported this cycle, but nobody rebuilt packages. done that.
[15:11] <doko> - made ruby-rspec build by dropping most of the test dependencies (universe)
[15:11] <doko> - ruby fixing, syncing, cursing ...
[15:11] <doko> - python3.5 rc3
[15:11] <doko> - openjdk-7, openjdk-8, openjdk-9 updates
[15:11] <doko> - MIRs, ruby package removals, syncs, merges, fix ftbfs's
[15:11] <doko> - s390x cross toolchains
[15:11] <doko> - s390x meeting
[15:11] <doko> - some more GCC triggered transitions nbs is clean again, update_output.txt as well.
[15:11] <doko> - started to re-enable pypy-* packages.
[15:11] <doko> (done)
[15:11] <tdaitx> * Short week, holiday on Monday (2015-09-07)
[15:11] <tdaitx> Current/Past
[15:11] <tdaitx> - Investigated a few
[15:11] <tdaitx> - 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] <tdaitx> - Refreshed patch to include dep3 info (Debian #794190)
[15:11] <tdaitx> - Found regression on JDK7 TLS 1.2 backports, investigating cause (LP: #1482924)
[15:11] <tdaitx> Next steps
[15:11] <tdaitx> - Refactor JRuby 3310 pull request
[15:11] <tdaitx> - Fix JDK TLS 1.2 regression
[15:12] <tdaitx> - Guarantee that local JCK 7 tests are running fine for trusty, then move those to canonistack
[15:12] <tdaitx> - Setup and use umt schroots, move them to canonistack
[15:12] <tdaitx> Waiting/On hold
[15:12] <tdaitx> - 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] <tdaitx> (done)
[15:12] <robru> (short week with labour day)
[15:12] <robru> lp:cupstream2distro
[15:12] <robru>  - set the request creator's name in debian/changelog rather than using ci train bot name.
[15:12] <robru>  - call checkUpload to enforce correct package upload permissions, ending honor system that used to be in place
[15:12] <robru>  - 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] <robru> (done)
[15:12] <pitti> sil2100 is on vac
[15:12] <pitti> systemd:
[15:12] <pitti>  - 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] <pitti>  - fix various regressions in trunk spotted by our daily(ish) upstream package builds, provide 226 in PPA for testing
[15:12] <pitti> autopkgtest:
[15:12] <pitti>  - Add fallback for dealing with build profiles with trusty's libdpkg-perl, to fix linux tests
[15:12] <pitti>  - Fix armhf/ppc64el autopkgtest runners to pull from ftpmaster.internal
[15:12] <pitti>  - Discuss kernel version reporting in tests with apw
[15:13] <pitti> misc:
[15:13] <pitti>  - Build new 15.04 langpacks with libusermetrics (#1484882)
[15:13] <pitti>  - Investigate NetworkManager test regressions; make some adjustments, file #1492126 and #1492168 for root causes
[15:13] <pitti>  - Some travel preps for the snappy sprint
[15:13] <pitti>  - usual daily -proposed cleanup/unblocking/investigations
[15:13] <pitti> [END]
[15:13] <barry> pitti: love the new summary at the end of adt-run
[15:13] <pitti> barry: me too! nice idea
[15:14] <pitti> barry: one of these 5 s improvements :)
[15:14] <barry> pitti: :)
[15:15] <slangasek> tdaitx: "unable to change status" - so we need to get you bug privileges still?
[15:17] <tdaitx> slangasek, possibly, I was not sure if I should have them already or just after I got in as a core dev
[15:18] <slangasek> 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] <infinity> I don't see why that MIR would need its status changed?
[15:18] <slangasek> 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] <bdmurray> tdaitx: https://wiki.ubuntu.com/UbuntuBugControl
[15:19] <bdmurray> "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] <slangasek> any other questions over status?
[15:21] <slangasek> [TOPIC] AOB
[15:21] <slangasek> pitti, bdmurray: there's a bug escalated by the phone team about apport that I'd like to get your input on
[15:21] <slangasek> bug #1278780
[15:21] <pitti> slangasek: I've seen it; you summarized it well
[15:21] <slangasek> ok
[15:22] <pitti> apart from the nice level tweakage I'm afraid I don't have any othe magic sauce to pour over this, though
[15:22] <infinity> 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] <slangasek> 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] <pitti> high nice level is better for background processes and worse for foreground, so maybe we should optimize for the latter
[15:23] <pitti> slangasek: but TBH I doubt that it'll make a noticeable difference
[15:23] <pitti> it might suck a tad less, but it'd still suck
[15:23] <slangasek> pitti: would you be ok with dropping the os.nice() call anyway, to see if it does make a difference?
[15:23] <pitti> slangasek: yes, I'm fine with that; I'd just not claim that this would fix the bug
[15:23] <doko> tdaitx, no need to redo the MIR, it already was approved. promoted that
[15:23] <slangasek> 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] <tdaitx> 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] <bdmurray> 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] <pitti> slangasek: I'm less sure about that (not famiilar with the innards of core dumps), but it seems likely
[15:24] <slangasek> bdmurray: yes, there have
[15:25] <slangasek> 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] <barry> on a different note, is anybody here a libunity expert (or know one)?
[15:25] <bdmurray> slangasek: alrighty
[15:25] <infinity> 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] <slangasek> 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] <bdmurray> it looks like Laney has been working on the ability to turn on and off crash reporting
[15:26] <slangasek> infinity, pitti: what if the system compositor had a custom SIGSEGV handler to unmap the video buffers and reraise the signal?
[15:27] <slangasek> bdmurray: there's a toggle for it in the UI that apparently doesn't work right currently
[15:27] <pitti> slangasek: that would certainly be very helpful
[15:27] <slangasek> pitti: "helpful" - but would it be sane? :)
[15:27] <infinity> "maybe".
[15:27] <bdmurray> slangasek: right, he's made some changes to whoopsie-preferences today see bug 1437633
[15:27] <pitti> slangasek: for most processes it shouldn't take that long, supposedly not manyu programs are handling huge gfx buffers
[15:27] <infinity> Manipulating memory after a crash is always iffy.
[15:27] <pitti> slangasek: absolutely, yes
[15:28] <infinity> 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] <pitti> slangasek: it's dramatically unlikely that a stack trace goes "through" the framebuffer, there should be no code there
[15:28] <pitti> slangasek: and in the end the stack trace is all that we keep anyway for a successful retrace
[15:28] <slangasek> bdmurray: right, that's the other bug that pmcgowan mentioned
[15:28] <pitti> slangasek: so freeing data can only be helpful
[15:28] <slangasek> pitti, bdmurray: so it seems at least worth suggesting this to the unity team
[15:28] <infinity> pitti: If the crash is in shader magic or something, it could absolutely be running rampant through video memory.
[15:29] <slangasek> infinity: would that show on the process stack?
[15:29] <pitti> infinity: well, we can't dump GPU code anyway, can we/
[15:29] <pitti> ?
[15:29] <infinity> slangasek: Hrm.  Probably not, I suppose.  Would just be an opaque call from libgl.  Probably.
[15:29] <infinity> I'm a bit rusty on all of that, it's been a decade since I lived with daniels.
[15:29] <pitti> 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] <pitti> err, the latter
[15:29] <slangasek> ok, I'll suggest this then, thanks
[15:30] <pitti> (not that unity having no bugs wouldn't be desirable..)
[15:30] <slangasek> (I'm not sure how much of the process's memory will actually be video buffers, but it's worth looking at)
[15:30] <pitti> slangasek: are you aware of the "gcore" tool?
[15:30] <slangasek> no
[15:30] <infinity> 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] <pitti> slangasek: quite handy for doing such comparisons without acutally having to crash your program
[15:30] <infinity> pitti: See all the Intel GPU vomit one gets in dmesg. :P
[15:31] <slangasek> pitti: ah nice
[15:31] <pitti> infinity: right, I thought X (or kernel or whatever) has some special apport hooks for that
[15:31] <infinity> pitti: X does, yes.
[15:31] <pitti> slangasek: so one could do gcore / do something to trigger video memory free / gcore again / compare
[15:31] <infinity> pitti: Mir probably wants the same ones.
[15:31] <slangasek> pitti: pmap might also give us the info we need for this
[15:32] <slangasek> infinity: if the phone were using KMS, sure ;)
[15:32] <slangasek> (yes eventually we want it for the desktop if we don't have it there already)
[15:32] <bdmurray> its probably worth noting that fixing bug 1437633 won't actually stop apport from creating crash reports
[15:33] <slangasek> ah because that's a setting for reporting crashes
[15:33] <slangasek> bdmurray: thanks for catching that
[15:33] <bdmurray> bug 1389407 might be better
[15:33] <slangasek> so really we're looking at an upstart override or something here
[15:34] <slangasek> right
[15:34] <slangasek> bdmurray: thanks
[15:34] <slangasek> anything else?
[15:34] <pitti> slangasek: bug updated
[15:36] <slangasek> going....
[15:36] <slangasek> going...
[15:36] <slangasek> #endmeeting
[15:36] <meetingology> Meeting ended Thu Sep 10 15:36:53 2015 UTC.
[15:36] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-09-10-15.03.moin.txt
[15:36] <slangasek> thanks, everyone!
[15:37] <caribou> thanks!
[15:37] <barry> thanks!
[15:37] <tdaitx> thanks!
[15:38] <pitti> thanks everyone!