[06:38] <pitti> Good morning
[06:39] <MasterPieceZ> moin pitti
[07:08] <pitti> infinity: I encountered some installability failures due to packages now relying on versioned provides; apparently that's implemented in a newer dpkg
[07:08] <pitti> infinity: are you planning to merge dpkg soon (TIL), or want me to look at this?
[07:27] <dholbach> good morning
[07:47] <seb128> dobey, hey, is bug #1367017 something you plan to look at? it's on top of e.u.c for utopic
[07:54] <seb128> bdmurray, do you know if https://errors.ubuntu.com/problem/355fe44c2df7fde28f2a6be90875fdd39632eee4 hits an e.u.c or apport bug?
[07:54] <seb128> the traceback is
[07:54] <seb128> "TypeError: string argument expected, got 'bytes'"
[07:54] <seb128> but that seems to be rather e.u.c failing to display the bt
[07:55] <pitti> not sure, but I've seen actual python exceptions that look like this
[07:57] <seb128> pitti, they would have a sourcefile/code/function indication though no?
[07:57] <pitti> seb128: that's what I mean with "like this" -- no traceback, just the exception
[07:57] <pitti> it's weird indeed
[07:57] <seb128> weird
[07:58] <pitti> very unlikely to be an e.u.c. bug; could be an apport bug, but I suspect the error just simply looks like that
[07:59] <seb128> k
[07:59] <seb128> so python bug?
[08:00] <pitti> or something in s-c-p intercepts the exception and does something like print(str(e))
[08:00] <pitti> (which is not that uncommon)
[08:00] <seb128> right
[08:00] <seb128> pitti, thanks
[08:01] <seb128> pitti, btw have you seen the s-c bug I just mentioned, is that something than changed in pygobject/an actual bug, or is that a warning that turns out to do e.u.c "spamming"?
[08:01] <seb128> bug #1361829 is high on the errors list with a similar issue
[08:12] <pitti> seb128: s-c-p was ported to py3 last cycle, so I figure it's an actual bug
[08:13] <seb128> pitti, that's software-center, not s-c-p?
[08:13] <pitti> seb128: the webapps one seems entirely different from the bytes vs. string conversion though?
[08:13] <pitti> seb128: ah, or that, sorry :)
[08:13] <pitti> seb128: no, https://errors.ubuntu.com/problem/355fe44c2df7fde28f2a6be90875fdd39632eee4 is s-c-p
[08:13] <seb128> pitti, sorry, I was refering to my ping to dobey from half an hour ago
[08:14] <seb128> pitti, s-c didn't change in utopic afaik
[08:14] <pitti> right
[08:14] <tsdgeos> ogra_: congratulations sir!
[08:15] <seb128> pitti, right, s-c didn't change at all, same revision in trusty and utopic
[08:15] <seb128> so it's coming from pygobject
[08:15] <ogra_> thanks tsdgeos !
[08:15] <seb128> well, it might be right to warn, but that creates errors noise :/
[08:28] <pitti> seb128: no, it's not a warning, it's a grave error
[08:28] <pitti> the warning was improved to make debugging easier
[08:28] <pitti> as otherwise it leads to random segfaults and similar
[08:28] <seb128> pitti, k, I wonder why we didn't get more reports from trusty if that's such an import error
[08:29] <seb128> s-c reports are quite low on trusty
[08:29] <seb128> and the code didn't change at all, not even a no change rebuild since
[08:30] <pitti> well, apparenlty it just happens to work then just in this case; but this imports glib/gobject etc. libraries twice, which is bound to fail
[08:30] <pitti> (i. e. it might just occur "randomly" if a library dependency changes, etc.)
[08:31] <seb128> right
[08:31] <seb128> dbarth, hey, you/your team is working on unity-webapps-* right? could you look at bug #1361829
[08:31] <seb128> dbarth, they are similar reports for the different webapps, that's ranked quite high on e.u.c
[08:34] <mvo_> pitti: quick question about the command-not-found blacklisting of postgres-xc  - it seems there are a bunch of additional postgres-xc-{client,...} packages, do we care about those as well ?
[08:34] <mvo_> pitti: care about blacklisting them I mean of course
[08:35] <pitti> mvo_: no, those should be fine as postgresql-common wraps the client-side programs
[08:35] <pitti> mvo_: but indeed the "initdb" program has the same issue, i. e. we should blacklist that in addition to pg_ctl
[08:36] <pitti> mvo_: bug title updated
[08:41] <dbarth> seb128: yes
[08:41] <dbarth> seb128: seen it, i assigned it now
[08:41] <seb128> dbarth, thanks
[08:42] <dbarth> seb128: the scripts choke on the gobject import
[08:42] <seb128> dbarth, right, should be easy to fix/change
[08:43] <dbarth> yeah; that's transitionary code that should be removed mostly
[08:43] <seb128> yeah, I was thinking that
[08:43] <seb128> those migrations scripts are probably not required anymore
[08:43] <seb128> maybe just drop them
[08:43] <dbarth> nope
[08:43] <dbarth> right
[10:32] <brainwash> can anyone help with a package which is stuck in trusty-proposed? bug 1377612
[10:35] <smb> Hm, is anybody already working on adding vivid to Trusty's dist-info-data?
[10:38] <pitti> smb: it's already there
[10:38] <pitti> at least I got it in a dist-upgrade
[10:39] <smb> pitti, hm... I just looked and only saw ubuntu0.1 which added Utopic...
[10:39] <pitti> smb: oh wait, sorry, that was debootstrap
[10:39] <pitti> right, I meant https://launchpad.net/ubuntu/+source/debootstrap/1.0.59ubuntu0.2
[10:40] <smb> pitti, Ah... yeah. I made a source pkg for distro-info-data. But not sure it is done right
[10:40] <smb> pitti, would you be able to have a look and sponsor if ok?
[10:40] <Laney> I already did a patch for it
[10:40] <Laney> check the queue
[10:43] <smb> hm... cannot find it in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=distro-info-data
[10:44] <Laney> the sponsor queue
[10:44] <pitti> brainwash: I asked elfy in #u-quality whether his comment 21 was testing the proposed package
[10:44] <smb> ah, sorry
[10:45] <pitti> brainwash: there's no other feedback on the update
[10:45] <Laney> I could just upload to proposed and let them copy to security I guess
[10:45] <pitti> -updates you mean? it's ceratinly not a -security thing?
[10:46] <Laney> look at the existing update
[10:49] <brainwash> pitti: so, someone needs to add a comment and state that he tested the trusty package, right?
[10:49] <pitti> brainwash: yes
[10:49] <brainwash> pitti: alright, thanks
[10:54] <brainwash> pitti: a comment has been added to the report
[10:54] <brainwash> https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1377612/comments/40
[10:55] <pitti> cheers
[10:57] <mgedmin> incidentally, why is chromium-browser in utopic older than in trusty?  http://packages.ubuntu.com/search?keywords=chromium-browser
[10:57] <mgedmin> utopic has 37.0.2062.94, trusty has 37.0.2062.120
[11:01] <Riddell> pitti: any tech board meeting today?
[11:01] <pitti> Riddell: yes, should be at 17:00 UTC
[13:02] <geser> mvo_: Hi, I see that you synced snappy and dropped the changes to make LP accept the upload (ancient timestamps). Are you going to re-add them or should I do it?
[13:08] <mvo_> geser: oh, that sounds like a mistake somewhere (probably me :/ - is it the touch in the rules file that is required for LP?
[13:12] <geser> yes
[13:13] <geser> it's needed for "libsnappy-dev_1.1.2-3_amd64.deb: has 2 file(s) with a time stamp too far in the past (e.g. usr/share/doc/libsnappy-dev/NEWS.gz [Mon Dec 31 23:00:00 1979])."
[13:13] <mvo_> geser: either way, i can fix but if you want to i'm happy too :)
[13:14] <geser> I would need a sponsor for it anyway
[13:16] <mvo_> ok, let me fix it then, thanks for letting me know and sorry for the trouble
[13:16] <dobey> seb128: i didn't know about that issue until just now. afaik, nobody is working on software-center. and distro-info-data apparently needs updated on trusty before pull-lp-source will work
[13:16] <seb128> dobey, there is a sru waiting on http://launchpadlibrarian.net/188495410/distro-info-data_0.18ubuntu0.2_source.changes
[13:17] <seb128> dobey, but s-c didn't change at all in utopic so you can get the trusty version through apt-get
[13:18] <dobey> right. i was trying to pull it off vivid, since i'll have to upload there first anyway
[13:19] <smoser> hey. so i have /var/crash/_usr_lib_unity_unity-panel-service.1000.crash .
[13:19] <smoser> dialog pops up, asks me if i want to submit, i say yes.
[13:19] <smoser> then nothing
[13:19] <smoser> is this functioning as designed ?
[13:19] <smoser> i'd like to see the bug it created.
[13:19] <smoser> same thing happens when i run 'ubuntu-bug /var/crash/_usr_lib_unity_unity-panel-service.1000.crash'
[13:19] <smoser> pitti, ^ do you know ? sorry for personal ping
[13:20] <pitti> smoser: it reports to errors.u.cc.
[13:20] <pitti> smoser: reporting to Launchpad bugs got disabled for final utopic release, as usual
[13:20] <smoser> ok. i thougth that might be the case.
[13:21] <smoser> might be useful to tell the user that ?
[13:21] <pitti> well, it does
[13:21] <pitti> never it says "Launchpad bug" or anythign :)
[13:21] <smoser> ok. yeah, i guess. it just doesn't say "i did it" but rather "do you want me to do it".
[13:24] <smoser> so lets say i wanted to see this bug. where do i do that ?
[13:24] <smoser> https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=unity-services&period=day tells me "no data to display"
[13:26] <pitti> 2014.10?
[13:26] <pitti> oh, %20, nevermind
[13:26] <mdeslaur> arges: hi! could you please take a look at the dovecot sru in the precise queue?
[13:27] <pitti> smoser: unsure, it might take a while to get processed?
[13:27] <arges> mdeslaur: sure. i'm working my way through the queues right now
[13:27] <smoser> pitti, thanks.
[13:27] <mdeslaur> arges: awesome, thanks :)
[13:27] <pitti> smoser: do you have a /var/crash/_usr_lib_unity_unity-panel-service.1000.uploaded?
[13:29] <smoser> yes
[13:29] <smoser> oh wait.
[13:29] <smoser> i have .upload
[13:29] <smoser> but not .uploaded
[13:30] <pitti> ah, then whoopsie didn't get to uploading it yet
[13:31] <pitti> /var/log/upstart/whoopsie.log might say why
[13:32] <smoser> http://paste.ubuntu.com/8719453/
[13:33] <pitti> bdmurray: ^ ?
[13:33] <smoser> well, 'sudo restart whoopsie'
[13:33] <smoser> got me to /var/log/upstart/whoopsie.log with: http://paste.ubuntu.com/8719461/
[13:34] <smoser> and got a .uploaded file.
[13:34] <smoser> but that doesn't really help me for the 2 things i'd hope to get out of this..
[13:34] <smoser> a.) i want to see the bug fixed.
[13:34] <smoser> well, i guess thats the only one. but i'd like ot subscribe to the bug.
[13:49] <smoser> pitti, i think i found it. i was being too specific with 'the package'. it is souce package.
[13:49] <smoser> https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=unity&period=week&pkg_arch=amd64
[13:50] <pitti> smoser: ah right, it is
[14:01] <arges> mdeslaur: for bug 1384355, there is an SRU to remove it from trusty/utopic. did you have any additional concerns/comments about this? I've read the thread on ubuntu-devel
[14:03] <mdeslaur> arges: not really, no. the approach Riddell took is fine by me. Nobody volunteered to take over maintenance, so I guess that's the best solution.
[14:04] <Riddell> arges: just needs someone from the ~ubuntu-sru team brave enough to approve it
[14:04] <arges> Riddell: yea, that's what i'm reviewing now : )
[14:04] <Riddell> yay
[14:08] <arges> Riddell: one thing is if its serving up this temporary php webpage, will it still need any of the deps like php5?
[14:10] <arges> Riddell: or i guess what would happen if I had a clean install of ubuntu-server; installed this package; how do I get the notification to use the upstream packages or juju?
[14:11] <Riddell> arges: I remove the dependencies didn't I?
[14:11] <Riddell> arges: it still installs the apache config so you can still browse to it and see the message
[14:12] <arges> Riddell: but the package has no dependencies now; so If you install it (without having the old package) how would you see those messages if you don't have those deps installed
[14:12] <Riddell> arges: apt-cache show owncloud will show you, message in /usr/share/doc/owncloud/README.Debian too
[14:13] <arges> you can't guarantee that apache2 | httpd, are installed
[14:13] <Riddell> I can add back apache2 | httpd if you think that would be better
[14:13] <arges> Riddell: ok so in the case of a new install from archive, we will have to assume the user will look at README.Debian or the apt-cache output
[14:14] <arges> Riddell: well i'm just thinking through it.
[14:15] <arges> so it handles two cases: 1) they have old package installed, and go to web portal which tells them to install through upstream.  2) they have a fresh install and we hope they read the messages somewhere in the package description, apt-cache, or README telling them to get the upstream version
[14:16] <bdmurray> seb128: I'd think an apport bug given that when you go to an individual problem page it is truncated there too.
[14:21] <Riddell> arges: yep
[14:22] <arges> Riddell: ok seems reasonable
[14:22] <Riddell> arges: I don't know what's common practice in empty SRUs like this, probably there is no common practice
[14:22] <Riddell> but it feels kindae wrong to install apache for an empty package
[14:23] <arges> Riddell: yea, i'd like to get a second opinion. i'll see if I can get somebody else to review too then i'd be happy accepting it
[14:33] <ricotz> hi, is it known the aptitude cant retrieve changelogs again?
[14:41] <mvo_> ricotz: what package(s) ?
[14:41] <mvo_> ricotz: i.e. how can I reproduce?
[14:42] <ricotz> mvo_, i would say all of them ;) (i know only official ubuntu archive ones should work)
[14:42] <mvo_> does anyone care about python-couchdb ? I would like to sync the debian version
[14:43] <ricotz> mvo_, select a package and "Shift+C"
[14:43] <mvo_> ricotz: right, I think I can reproduce this - just to double check "apt-get changelog pkgname" for the same package works, right?
[14:44] <ricotz> mvo_, yes
[14:45] <mvo_> thanks
[14:47] <mvo_> ricotz: could you please report a bug so that we can SRU a fix?
[14:58] <ricotz> mvo_, https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1386737
[14:58] <mvo_> ricotz: thanks!
[14:58] <Laney> This libtool dependency shuffling...
[14:58] <Laney> should dh-autoreconf depend on libtool-bin now?
[15:21] <infinity> pitti: I was intentionally holding off for a bit, as the Debian uploads had been frequent and bugfixy.
[15:22] <pitti> infinity: ah, ok; that's fine, I just wanted to know the status
[15:23] <infinity> pitti: Though, people jumping on the versioned provides bandwagon as soon as the feature exists seems misguided.  Whee.
[15:24] <pitti> infinity: yeah, I agree; and I still think it's a bad idea in the first place :/
[15:24] <pitti> this is way too prone to errors
[15:25] <infinity> pitti: Aaand, more regression fixes over the weekend.  I think I'll let dpkg bake a tiny bit longer. ;)
[15:25] <pitti> infinity: ack :)
[15:25] <pitti> infinity: something else; bug 1381656, is that something that ought to be fixed in Debian, or is that file ubuntu specific?
[15:26] <rbasak> What's the new feature, OOI?
[15:27] <pitti> rbasak: versioned provides
[15:27] <infinity> pitti: Possibly Ubuntu-specific, since we build for a different target.
[15:27] <rbasak> Ah
[15:27] <pitti> AFAIK, if you have
[15:27] <pitti> Package: foo
[15:27] <pitti> Version: 3
[15:27] <pitti> Provides: somefoo
[15:27] <pitti> then you can have "Depends: somefoo (>= 2)" and foo would satisfy this
[15:27] <infinity> pitti: To be fair, internally, provides were always versioned, but the version was 0. :P
[15:28] <rbasak> That's nice, although it feels like a binary package version shouldn't be tied to the version of the virtual thing that it provides?
[15:28] <pitti> but foo/1 wouldn't satisfy this (that's the real new thing)
[15:28] <pitti> rbasak: yeah, that's the "brittle" part that I don't like
[15:28] <rbasak> I'd have done it as "Provides: somefoo (=3)" or something
[15:29] <infinity> That's how it's done.
[15:29] <infinity> pitti: What gives you the idea it's using the non-provided version?
[15:29] <pitti> the above is the case that I saw this morning
[15:30] <pitti> meeting, bbl
[15:30] <infinity> rbasak: It's implemented exactly as you think it should be. :P
[15:30] <rbasak> infinity: nice :)
[16:17] <sergiusens> pitti: hey, is there a way to run adt tests for a deb from local sources?
[16:17] <pitti> sergiusens: yes (in meeting); see https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html
[16:17] <pitti> sergiusens: can help you in a bit after meeting
[16:19] <sergiusens> pitti: I'll follow the docs, was using https://wiki.ubuntu.com/QATeam/AutomatedTesting/AutoPackageTesting though
[16:19] <sergiusens> thanks
[16:19] <pitti> sergiusens: ah thanks, I'll remove that; it's obsoleted by the autopkgtest docs and http://packaging.ubuntu.com/html/auto-pkg-test.html
[16:42] <pitti> sergiusens: wiki page updated; meeting done, do you still have questions/trouble?
[16:42] <pitti> sergiusens: and yes, you can test a local .deb, a local .dsc, or both
[16:42] <pitti> sergiusens: or a local source package dir (built or unbuilt)
[16:46] <pitti> mvo__: thanks for fixing bug 1384864!
[16:47] <pitti> mvo__: OOI, how do you do that? manually editing scan.data after scanning, or is there a more clever way? (I'm looking at https://launchpadlibrarian.net/188488665/command-not-found_0.3ubuntu15_0.3ubuntu15.1.diff.gz)
[16:54] <pitti> infinity, kees, mdeslaur, stgraber, slangasek: TB meeting reminder (6 mins)
[16:55]  * slangasek nods
[16:55] <slangasek> who's chair today?
[16:55] <infinity> Oh whee, I'm chair.  I get to remind myself how to use the bot again.
[16:55]  * ogra_ sits down on infinity to test that claim
[16:56] <ogra_> not so comfortable ...
[16:56] <infinity> Ow.
[16:56] <ogra_> you need some more stuffing :)
[16:56] <infinity> I have plenty, thanks.
[16:56] <ogra_> heh
[16:59] <infinity> pitti: I assume we still have the conflict that forces us to #-meeting-2?
[16:59] <pitti> infinity: according to http://fridge.ubuntu.com/calendars/fridge/ yes (kernel team meeting)
[17:00] <sergiusens> pitti: I think I can take it from here, still setting up anyways; thanks!
[17:00] <pitti> hm, why isn't the TB meeting on this any more -- it used to
[17:00]  * rbasak didn't realise the TB was DST-compliant
[17:00] <infinity> kees: Joining us in #-meeting-2?
[17:00] <kees> infinity: yup, almost there
[17:00] <pitti> rbasak: we are all on the nothern hemisphere, so much better that way (we pinned to London time instead of UTC)
[17:01] <rbasak> Makes sense.
[17:02] <pitti> bdmurray: FTR, I updated lp-retracer-config for vivid and rolled out to LP retracers; I figure daisy needs some similar treatment
[17:05] <bdmurray> pitti: thanks, is there any reason not to turn on crash reporting to Errors earlier than we usually do?
[17:08] <pitti> bdmurray: we never disable crash reporting to errors
[17:08] <pitti> bdmurray: only to launchpad
[17:08] <pitti> bdmurray: (for stables) ^
[17:10] <pitti> bdmurray: responded to bug 1365079
[17:12] <dpm> pitti, do you know who could do a sync from a utopic package to rtm while Colin is away?
[17:13] <pitti> dpm: any archive admin can do that (me too)
[17:13] <Laney> Anyone who can upload in fact
[17:13] <pitti> oh, even better
[17:13] <Laney> (AIUI)
[17:14] <ogra_> dpm, note that nothing is allowed to enter rtm without being on ollis list
[17:15] <ogra_> (except langpacks i think)
[17:15] <dpm> ok, I'll talk to olli, thanks ogra_ and everyone
[17:15] <ogra_> (and you will need QA signoff too)
[22:19] <slangasek> why are my terminal fonts a complete disaster after a system restart in 14.10?
[22:20] <slangasek> in fact, something seems to have changed mozilla's theming too
[22:25] <sladen> slangasek: /usr/share/glib-2.0/schemas/ubuntu-artwork.gschema.overide ?
[22:26] <sladen> slangasek: ... just a guess, but if you're seeing multiple things changed, it could be the whole set of default-overrides missing
[22:29] <slangasek> hmm.  unity-settings-daemon was running but not working correctly
[22:29] <slangasek> so killall unity-settings-daemon, and my terminal fonts are suddenly not eyebleeding
[23:07] <ari-tczew> I'm trying to upload a source package to vivid-proposed.
[23:07] <ari-tczew> $ dput ubuntu:vivid-proposed gnome-shell-extensions_3.14.1-1ubuntu1_source.changes
[23:07] <ari-tczew> However, files have been uploaded to utopic-proposed
[23:07] <ari-tczew> what's wrong?
[23:08] <Bluefoxicy> okay so is there a tool to reverse the update from 14.04 to 14.10
[23:08] <Bluefoxicy> because there was no warning on 14.10 that it was mid-development
[23:08] <Bluefoxicy> and everything is broken in this release
[23:10] <ari-tczew> Bluefoxicy: new, fresh install the best. for such questions better please ask on #ubuntu
[23:19] <TheMuso> ari-tczew: Um, I ddn't think you could upload to a release like that, I thought the release you wanted the upload for needs to be mentioned in the changes file.
[23:27] <Bluefoxicy> okay well, entering #ubuntu is the most useless thing anyone can evere do
[23:27] <Bluefoxicy> so I'll just file a bug "It doesn't work and I have no idea why, nor any way to collect any information explaining why.  Good luck."
[23:35] <ari-tczew> Bluefoxicy: so good luck while waiting for constructive response.
[23:36] <ari-tczew> TheMuso: Right, there was a problem. thnx :-)
[23:37] <Bluefoxicy> ari-tczew:  there is no way to get constructive information
[23:37] <Bluefoxicy> it's broken, and there's no debug output, and no information on the internet, and everyone says "LOL HTML5 VIDEO INSTALL FLASH???"
[23:37] <Bluefoxicy> That's the type of constructive response I got from #ubuntu
[23:37] <Bluefoxicy> "HTML5 video doesn't play" "Have you installed Flash?"
[23:39]  * ari-tczew is leaving topic as won't fixed.
[23:47] <sladen> Bluefoxicy: what exact URL does not player, in what exact browser?
[23:51] <Bluefoxicy> sladen: https://www.youtube.com/watch?v=jHMmMgdcOSU https://www.youtube.com/watch?v=A_FFF3wgfh8 https://www.youtube.com/watch?v=ZNL72qFc_ew https://www.youtube.com/watch?v=PN7O9gM-lvc https://www.youtube.com/watch?v=FSLUXkfm9b8 https://www.youtube.com/watch?v=fouoxaWGFng
[23:51] <Bluefoxicy> sladen:  do not play in Chromium-browser.  They were playing in 14.04; they're mostly open because they were open in 14.04 and Chromium re-opens tabs when it restarts.
[23:51] <Bluefoxicy> If I click and scroll and such, I can scroll through the video to any frame in the video
[23:51] <Bluefoxicy> The ads don't play either.
[23:53] <Bluefoxicy> I tried apt-get remove --purge chromium-browser, removing ~/.config/chromium, and then re-installing chromium-browser and starting up again with no config in my user directory and with the system config purged and recreated
[23:53] <Bluefoxicy> that didn't fix it.
[23:53] <Bluefoxicy> I'm out of troubleshooting actions :|
[23:54] <Bluefoxicy> I can't gather any information on why it's behaving this way, I can't find anything online about it, and I can't get a proper result with a cleared configuration.  This is bang-your-head-against-the-wall territory.
[23:56] <Bluefoxicy> watch
[23:56] <Bluefoxicy> I'll be the only person in the world this is happening to
[23:57] <geofft> I've seen that behavior before but I forget what caused it.
[23:58] <geofft> I did once have chromium-codecs-ffmpeg* out of sync with chromium-browser itself, which caused somethings to be sad
[23:58] <geofft> but I think the symptoms were different.
[23:58] <Bluefoxicy> geofft:  have you also seen the behavior of "Activities view hangs gnome-shell for 5 seconds, or possibly crashes it" too?  because that happens too.
[23:58] <geofft> no, but now I'm suspecting your libGL...
[23:58] <Bluefoxicy> Upgrading from 14.04 to 14.10 didn't really bring anything new except a slew of brokenness.  It should have been called do-release-update, because "upgrade" implies making it better.