[01:48] <xnox> superm1: i have a simple reproducer.... it's pointing at a gtk regression =)))
[01:51] <hyperair> RAOF: okay, i found it. turns out it's ccsm > opengl > enable fbc
[01:52] <RAOF> hyperair: You mean texture compression, or framebuffer object?
[01:52] <hyperair> RAOF: if that's enabled, compiz blacks out when trying to accomodate to a change in the display configuration
[01:52] <hyperair> RAOF: texture compression
[01:52] <RAOF> Huh, fun.
[01:53] <hyperair> mm
[01:53] <hyperair> do you see the bug too?
[01:55] <RAOF> hyperair: Not exactly the same as you; I instead get seizure-provoking 60Hz flicker between a previous mostly-correct frame and black.
[01:55] <hyperair> ugh
[03:07] <superm1> xnox: well that's actually great to hear
[03:08] <superm1> can you share the simple reproducer?  whatever it is about what's happening in that page can probably be switched to something else to avoid hitting this bug in the short term
[03:08] <superm1> and long term get the GTK bug fixed
[03:09] <xnox> superm1: yeah, i'm trying to work on it. I think if i tweak/fake environment enough it may just work. bug #1306341
[03:10] <xnox> superm1: the problematic things appear to be the "filechooser" buttons in tab_remote.ui but i'm checking things further.
[03:10] <superm1> ah interesting
[03:11] <xnox> superm1: looking at the glade file vs installer ui -> are the buttons to select configuration file actually used?
[03:12] <superm1> xnox: they're used in something else that uses the mythbuntu-common package
[03:12] <xnox> superm1: oh, ok.
[03:12] <superm1> lemme double check if they can be ripped out though
[03:12] <xnox> superm1: lemme check if that's the only issue.
[03:13] <superm1> i'd be surprised if that was the only issue; since taking the services page / plugin out of the picture fixed it, not the remote one
[03:14] <xnox> superm1: probably the plugins were removed in the wrong order. So nuking myth-services would also nuke myth-remote.
[03:15] <superm1> ah
[03:15] <xnox> superm1: since myth-remote is after myth-services.
[03:15] <xnox> but i'll check that as well.
[03:16] <superm1> the file chooser dialog was used for configuring a remote custom configuration; that whole thing is littered with bugs, i wouldn't mind just axing it if it fixes this
[03:17] <superm1> i'll take out the associated code and see
[03:17] <xnox> superm1: i'm aiming for a one-line fix only =)
[03:18] <Logan_> xnox: to whom should I talk if I want to become part of ~udd?
[03:19] <xnox> Logan_: anyone, but why would you want to? all you'll gain is commit access to lp:udd branch and that's it.
[03:19] <xnox> Logan_: what are you after in terms of permissions/capabilities?
[03:19] <Logan_> requeue_package.py 😛
[03:19] <Logan_> oh god I really need to turn off this automatic emoji replacement
[03:20] <xnox> Logan_: start here http://www.canonical.com/careers/all-vacancies ; once you get one of those, we could sort you out access =)
[03:20] <Logan_> if Canonical offered internships, I'd be all over that
[03:21] <xnox> Logan_: it's running on a publically inaccessible machine, under an elevated celebrity account to push the branches to launchpad =
[03:21] <xnox> =/
[03:21] <Logan_> oh wonderful
[04:03] <xnox> superm1: mid-air collision!
[04:04] <xnox> superm1: http://bazaar.launchpad.net/~xnox/mythbuntu/fix-myth-passwords/revision/201
[04:04] <xnox> superm1: but your way is fine as well. Please land that.
[04:05] <xnox> superm1: the other bug, i'm fixing in ubiquity by doing this - http://paste.ubuntu.com/7233456/
[04:05] <superm1> xnox: hah wow talk about funny timing
[04:05] <xnox> superm1: seconds difference upon push.
[04:05] <superm1> your way actually scales better for any changes in future
[04:06] <superm1> i've got a tear out of the filechooser stuff too that appears to resolve things as well
[04:07] <xnox> superm1: don't.
[04:07] <xnox> superm1: all works fine with http://paste.ubuntu.com/7233456/ applied to ubiquity
[04:07] <superm1> ok
[04:08] <xnox> superm1: i'm landing that for ubiquity.
[04:08] <xnox> superm1: if you are ok with myth-password change, then i can upload that as well.
[04:08] <xnox> superm1: trumping your commit.
[04:08] <superm1> yeah go ahead and upload that
[04:08] <superm1> can you commit it to ~mythbuntu-dev bzr too?  I think all ~ubuntu-dev is able to
[04:11] <Mirv> if there's a core-dev awake, we'd need a packaging ack for messaging-app https://ci-train.ubuntu.com/job/landing-015-2-publish/10/artifact/packaging_changes_messaging-app_0.1+14.04.20140410.1-0ubuntu1.diff
[04:11] <Mirv> (tested + QA signed off)
[04:12] <Mirv> there's not much to ack though
[04:27] <xnox> superm1: both ubiquity & mythbuntu-live* packages uploaded. When they get accepted tomorrow, i'll ask for mythbuntu iso respin and i will test it out.
[04:27] <superm1> xnox: awesome, thanks so much
[04:28] <xnox> superm1: no problem, the HOME fix should actually also resolve a few things across the board - e.g. pango, dconf etc complaining. none of them were fatal so far...
[04:29] <xnox> superm1: so I'm happy about it. Still - why gtk decides to assert is beyond me.
[05:15] <pitti> Good morning
[05:15] <pitti> barry: :(
[05:37] <pitti> infinity: mmmmm, "final release of Saucy Salamander in a week." :)
[05:38] <pitti> ah, and the followup mail :)
[05:41] <pitti> barry: but thomi landed the AP branch to drop the deps
[05:44]  * hyperair wonders where the zsh manpages are..
[05:47] <StevenK> hyperair: Replaced by info pages, as far as I can see.
[05:47] <hyperair> really?
[05:48] <hyperair> i thought they used to be there together with the info pages
[05:48] <hyperair> in fact, zsh-common still has a dangling zsh5 manpage link
[05:48] <hyperair> symlink*
[05:49] <hyperair> also...
[05:49] <hyperair> hyperair@thinkpwn:~(1)% run-help autoload                                                                                                                                                                                     [ 1:49PM]
[05:49] <hyperair> autoload is a shell builtin
[05:49] <hyperair> meh
[05:49] <hyperair> No manual entry for zshbuiltins
[05:54] <pitti> infinity: and the langpack fun begins :)
[05:57] <hyperair> xnox: ping. are the zsh manpages meant to be missing?
[05:58] <StevenK> hyperair: Are they in the source package?
[05:59] <hyperair> StevenK: dunno, i'll need to check.
[05:59] <hyperair> StevenK: but debian has its manpages intact at least
[06:01] <hyperair> StevenK: okay, for some reason we have a downstream ubuntu patch that disables building of docs
[06:01] <hyperair> manpages included
[06:02] <hyperair> and a changelog entry from xnox adding the patch
[06:02]  * hyperair has no idea why
[06:02] <StevenK> No bug referenced or anything?
[06:03] <hyperair> nope
[06:03] <hyperair> no dep3 headers either
[06:03] <hyperair> just.. patch.
[06:03] <StevenK> It's in main, but I seriously doubt it's on the CD, so WTF
[06:04]  * hyperair shrugs
[06:04] <hyperair> that's why i pinged
[06:04] <StevenK> hyperair: It's a good plan, I want to know too.
[06:23] <slangasek> hyperair: the explanation in the changelog says:
[06:23] <slangasek>     - Keep using the upstream tarball that contains pre-generated docs as
[06:23] <slangasek>       yodl is required to build them but the MIR hasn't been approved.
[06:23] <hyperair> oh blargh
[06:24] <slangasek> so the docs are assumed to be present in the upstream tarball
[06:24] <hyperair> i see
[06:24]  * hyperair didn't spot that entry
[06:40] <pitti> wgrant: I'm disabling the saucy langpack build cron job now; please feel free to do the same on LP
[07:28] <Mirv> if http://bazaar.launchpad.net/~timo-jyrinki/ubuntu/trusty/lmms/1.0.0_packaging/revision/45 looks correct (chiefly silencing pkg-has-shlibs-control-file-but-no-actual-shared-libs), then https://code.launchpad.net/~timo-jyrinki/ubuntu/trusty/lmms/1.0.0_packaging/+merge/215131 would be ready
[07:28] <hyde> I just filed a bug report about patch (possibly duplicate, did not check....), but I wonder if someone here could shed some light on, how can command line argument handling of a program like patch get so broken, that it throws segfault?
[07:28] <Mirv> but I hesitate with the shlibs, whether it should be there at all or if there should be some manual shlibs file
[07:41] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1254028
[07:41] <LocutusOfBorg1> hi, anybody wants to sponsor this?
[08:54] <Mirv> mvo: would you have time to give DDTP a health check? ie. syncs from Debian (looks like last in Nov/Dec) + uploads to archive/mirrors (not sure how to check if done recently).
[08:55] <Mirv> or if there are other people who know the DDTP magic
[09:13] <caribou> pitti: can I come and bug you about apport for a few minutes ?
[09:16] <pitti> caribou: just ask :)
[09:17] <caribou> pitti: PM
[09:42] <xnox> hyperair: bug #1242108
[09:42] <hyperair> xnox: ah, thanks.
[09:42] <hyperair> oh crap, my launchpad.net session was expired
[09:43]  * hyperair tries to remember password
[10:07] <infinity> pitti: The one to -announce was slightly more right, the -release readers get a treat.
[11:28] <Chipaca> who should I pester about https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1304265 ?
[11:29] <seb128> Chipaca, try asking bregma about it
[11:29] <Chipaca> seb128: ta, will do
[11:29] <seb128> yw
[11:29] <Chipaca> but first i think i'm going to grab me some lunch
[11:29] <Laney> #ubuntu-unity more generally
[11:29] <Chipaca> okie doke
[11:30] <Chipaca> Laney: good point :)
[11:30] <seb128> the channel is mostly ovetaken by unity8 discussion though, so unity desktop questions might not get a reply, check with bregma if that happens, he's leading the team working on the desktop issues
[11:54] <doko> pitti, uploaded python3.4. fixed all the new testsuite errors, caused by moving around binary test cases which don't appear in the diff. there is one still failing, which I documented and disabled for now so that the autopkg tests pass
[13:52] <infinity> mvo_: Since when does apt allow # as a comment char in configs?
[13:52] <infinity> mvo_: It certainly didn't used to (which makes the aptdaemon change odd)
[13:53] <cjwatson>   * [ABI break] support '#' in apt.conf and /etc/apt/preferences
[13:53] <cjwatson>     (closes: #189866)
[13:53] <cjwatson> apt 0.7.22
[13:54] <infinity> cjwatson: Oh.  So maybe what I'm thinking of is that aptdaemon's tests failed when we tried to use #, not that apt didn't allow it. :)
[13:54] <infinity> (I remember we added a config file with # and switched to // because of a failure somewhere)
[13:55] <infinity> Probably the kernel autoremove stuff.
[13:58] <apachelogger> any has a clue why kde-runtime is blocked from proposed migration?
[13:58] <apachelogger> excuses says it's waiting for autopkgtest for libreoffice 1:4.2.3~rc3-0ubuntu2: RUNNING
[13:58] <apachelogger> although that seems to have failed on a tooling exception
[14:00] <mvo_> infinity: indeed, the kernelautoremove stuff
[14:01] <infinity> mvo_: Right.  We switched to // thinking # wasn't supported, but that was probably because of the bug in aptdaemon. ;)
[14:02] <mvo_> infinity: yeah, that sounds likely :)
[14:02] <mvo_> infinity: anyway, thats fixed now and the other failures should be fixed too, one real bug in the py3 switching that probably prevernts dpkg from installing single debs, otherwise mostly missing dependencies etc
[14:10] <ScottK> pitti: Would you please have a look at the latest libreoffice test on i386.  Something seems to have gone horribly wrong in Jenkins.
[14:11] <DevilsOwn> Hello
[14:12] <DevilsOwn> I wanted to ask something related to the ubuntu-server boot process
[14:12] <DevilsOwn> anybody here?
[14:17] <dobey> DevilsOwn: #ubuntu-server is probably a better place
[14:17] <dobey> DevilsOwn: and just ask, don't ask to ask
[14:20] <DevilsOwn> sure!
[14:44] <bdmurray> mvo_: Do you know what would call "pkexec /usr/lib/update-notifier/package-system-locked"?
[14:46] <seb128> bdmurray, http://ubuntu-codesearch.surgut.co.uk/search?q=package-system-locked suggests nothing
[14:47] <bdmurray> seb128: hunh, that's a neat site
[14:47] <seb128> bdmurray, indeed ;-)
[14:48] <bdmurray> I'd received and authentication dialog with the message that search returned.
[14:53] <mvo_> bdmurray: ubuntu-system-service might be
[15:26] <doko> mvo_, suggestion here from PyCon ... lp: #1306682  can we still do this for trusty?
[15:27] <jrwren> i don't think python would ever not be found. ubuntu doesn't run without python, does it?
[15:29] <xnox> jrwren: both python and python3 have been removed from minimal ubuntu core installations a few cycles back.
[15:30] <jrwren> xnox: good to know. thanks.
[15:30] <xnox> doko: suggestion here from Greenwich, implement "from __future__ import unicode_str" =)
[15:32] <doko> ynox: that's backward =)
[15:32] <jrwren> hahaha, on 12.04 if you try to remove python-minimal, apt sasy "You are about to do something potentially harmful."
[15:33] <xnox> doko:i think we do have overrides in command-not-found to do such a trick.
[15:33] <xnox> jrwren: yes, it used to be marked essential, it isn't anymore. I think we did that in saucy or raring.
[15:34] <jrwren> xnox: understood. I didn't mean to suggest you were wrong. 12.04 is definitely more than a few cycles back.
[15:34] <jrwren> I just thought it was funny.
[15:34] <jrwren> I've not seen that messge before.
[15:34] <rbasak> I don't follow how this would work. "python"..."apt-get install python3!"...ok...<does it>..."python"..."apt-get install python3!"...?
[15:34] <superm1> xnox: all the pieces look to have landed in the archive, can you respin the ISO now?
[15:34] <rbasak> http://www.python.org/dev/peps/pep-0394/ is pretty clear that python must mean Python 2.
[15:35] <rbasak> Well, "should"
[15:35] <rbasak> doko: ^^?
[15:35] <xnox> rbasak: it would work like this "did you mean python3 ? for python2 install package python"
[15:35] <xnox> rbasak: we will not make python symlink to -> python3
[15:36] <rbasak> xnox: ah. That makes sense :)
[15:36] <doko> rbasak, we only make aunannounced version updates with ruby =)
[15:37] <rbasak> doko: yeah I didn't think that you were suggesting changing the symlink. I just wondered how the message would help without causing an infinite loop. xnox's explanation works for me :)
[15:39] <doko> rbasak, yep, just wanting to point people to the new version
[15:40] <jhenke> hi, somebody here know why the daily installer from today installed libc* packages in version 2.19-0ubuntu5 while the archive just has 2.19-0ubuntu4?
[15:40] <infinity> jhenke: Look again?
[15:40] <infinity>  libc6 | 2.19-0ubuntu5      | trusty           | amd64, arm64, armhf, i386, powerpc, ppc64el
[15:41] <infinity> jhenke: If "the archive" only has ubuntu4, you're using an out-of-date mirror.
[15:41] <jhenke> infinity I had it query several time already
[15:42] <jhenke> never had that before, was by default on mirror for germany
[15:42] <jhenke> maybe somebody wants to check that?
[15:44] <infinity> jhenke: Looks like their upstream (ftp.uni-kl.de) hasn't updated for ~8h
[15:45] <infinity> jhenke: Probably just an temporary problem, but switching from de.archive.ubuntu.com to gb.archive.ubuntu.com for now would fix you up.
[15:45] <jhenke> well yes I am not to the main mirror for the time being
[15:46] <jhenke> just want to point out, so somebody might be able to tell the mirrors admin to check the machine
[15:46] <mvo_> doko: let me check
[15:46] <infinity> jhenke: Given the heartbleed madness this week, people taking services offline for a few hours here and there isn't something worth bugging them about, to be fair. :P
[15:47] <infinity> jhenke: (Heck, my local government has shut down half their public-facing services for a good chunk of the week)
[15:48] <jhenke> hmm, if you say so
[15:53] <bdmurray> dobey: I feel like the SRU for bug 1306225 could be more informative, like have a hyperlink to the announcement.
[16:09] <xnox> superm1: i don't have powers to respin, can you click the respin buttons on http://iso.qa.ubuntu.com/ ?
[16:10] <xnox> superm1: or i'll poke ~cdimage people.
[16:10] <xnox> superm1: i did upgrade in the livecd and tested and that worked fine.
[16:11] <Laney> I don't think mythbuntu has that set up
[16:11] <Laney> superm1: xnox: you want one?
[16:11] <xnox> Laney: yeah i want mythbuntu i386 and amd64 respin.
[16:11] <Laney> ok
[16:12] <Laney> there
[16:12] <xnox> Laney: ta!
[16:14] <dobey> bdmurray: a link where? you're welcome to discuss it with beuno and others. i didn't make the patch, i'm just doing the packaging for it
[16:15] <beuno> dobey, to the blog post?
[16:15] <beuno> that seems to be what bdmurray is implying, which sounds sane
[16:16] <dobey> yes, i was asking where in the UI
[16:16] <dobey> ubuntuone-client has no UI, and links in notifications is not a nice thing
[16:18] <bdmurray> beuno: right, there is no easy way for people to find out why or get more information.
[16:20] <xnox> dobey: beuno: i presume the control panel shows "error syncing" maybe that could show a better message after 1st of june e.g.  "these services are no longer offered"
[16:20] <xnox> ditto indicator-sync and/or cmd line utilities / logs that generated for syncing.
[16:21] <dobey> xnox: i'd prefer to just not do anything
[16:21] <dobey> bdmurray: well we've already e-mailed every user we have
[16:22] <xnox> dobey: fair enough =) if people ignore planet, blogs, news sites, emails they recieved and refunds..... it's really their own fault by 1st of june ;-)
[16:22] <dobey> xnox: well then they can figure it out and go to the web site and download a zip of all their data or something
[16:25] <bdmurray> dobey: I think emails are easily missed, I don't recall receiving one and its not much work to point to the blog announcement is it?
[16:25] <beuno> bdmurray, emails are still going out
[16:25] <dobey> bdmurray: it depends
[16:26] <dobey> bdmurray: and we couldn't do it in ubuntuone-client really, we'd have to put it somewhere there is actual UI
[18:07] <rohan> hi: can someone familiar with xorg tell me if this bug needs any more info?
[18:07] <rohan> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1282867
[18:07] <rohan> it is a pretty serious bug affecting intel GPUs on trusty
[18:07] <dobey> yeah, don't file one bug that has a title of "many bugs" and don't say "likely caused by"
[18:08] <dobey> assumptions aren't helpful
[18:11] <rohan> dobey: and that was helpful how?
[18:12] <rohan> did you even bother looking at the bugs, and the logs provided?
[18:12] <rohan> and "many bugs" refer to graphical glitches, not launchpad bugs.
[18:13] <dobey> no, because i'm not an intel driver developer, and the summary is not helpful to me even if i was
[18:13] <dobey> you asked for help, i gave you some helpful advice; if you don't like it, don't complain about it
[18:13] <rohan> sorry, but how is the summary not helpful?
[18:13] <dobey> you're free to ignore if you wish
[18:13] <rohan> no, you crticised without giving any constructive advice.
[18:14] <dobey> as i said, it says "many bugs" and it is making an assumption about the cause
[18:14] <rohan> the summary has the dmesg log outputs, and the corresponding driver and package versions
[18:14] <dobey> whatever
[18:14] <rohan> if i can do something to improve it, let me know, otherwise you are the one making assumptions :)
[18:15] <rohan> also, my assumption was not stupid: disabling SNA actually fixed the problem, so it *is* likely caused by SNA
[18:15] <dobey> sigh
[18:15] <dobey> i didn't say it was stupid
[18:15] <dobey> i said it was an assumption
[18:15] <dobey> and i don't have time to have a stupid argument about that with you
[18:19] <rohan> dobey: well then, you needn't have bothered looking at it and giving unconstructive suggestions, right?
[18:25] <rohan> dobey: in the spirit that you're a developer and probably know more than me, i've updated the title of the bug.
[18:32] <pitti> doko: yay, thanks
[18:32] <pitti> ScottK: seems it's back to normal, jibel kicked it
[18:33] <pitti> ScottK: and yes, jenkins is acting up a lot recently, mostly due to the unreliable ppc64el boxes; I'm working on a replacement system to avoid jenkins entirely :)
[18:34] <ScottK> pitti: Thanks.  I overrode it so we weren't blocked, but it's good to know it's working again.
[18:35] <pitti> ScottK: yep, https://jenkins.qa.ubuntu.com/job/trusty-adt-libreoffice/333/ is the latest
[18:35] <pitti> 334 is currently running
[18:42] <pitti> infinity, smoser: can you please kick wolfe-05? ssh takes ages, and sudo reboot is just stuck; I guess the zero-page memory corruption bug wreaked enough havoc
[18:42] <pitti> I'd like to reboot, dist-upgrade, refresh the container, and put it back on jenkins duty
[18:55] <infinity> pitti: Lemme have a look.
[18:56] <infinity> pitti: 5, you say?
[18:58] <infinity> pitti: Should be back.
[19:41] <smoser> thanks infinity .
[19:41] <smoser> pitti, did you want an entirely clean system ?
[20:23] <jtaylor> cjwatson: broken grub-probe with lvm snapshots should probably go into the release notes for 14.04
[20:24] <jtaylor> disabling the os-prober is probably a reasonable workaround for isntallation/upgrade
[20:24] <jtaylor> I had a short look at why it breaks, but this issue is over my head :/
[20:25] <cjwatson> jtaylor: I uploaded the fix today ...
[20:25] <jtaylor> oh
[20:25] <cjwatson> analysis in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1287436
[20:25] <jtaylor> I just tried it, though maybe I did apt-get upgrade to early
[20:26] <jtaylor> ah my mirror hasn't got it yet
[20:26] <jtaylor> thanks
[20:26] <jtaylor> I'll test it when its available
[20:26] <cjwatson> Thanks.  I tested in a Xen guest with unstable
[20:27] <jtaylor> its pretty easy to reproduce if you are using lvm, just create a snapshot and do update-grub2
[20:27] <cjwatson> It wasn't obvious - first two or three guesses as to the cause turned out to be entirely wrong when I actually compared against 2.00's behaviour in detail
[20:27] <cjwatson> Right, that's what I did
[20:28] <cjwatson> 2.00's grub-probe actually didn't understand snapshots properly either, it's just that grub-mkconfig didn't fail in that situation
[20:29] <cjwatson> I was initially confused because it worked with upstream 2.00, but that's because an entirely different bug in grub-mount (patched in my packaging) masked it
[20:32] <bdrung> xnox: can you update app-install-data-ubuntu again for picking up the fixed sonic-visualiser (bug #1161283)?
[20:38] <bulletxt> thanks for updating cups 1.7.2 in ubuntu 14.04
[22:50] <darkxst> can somebody upload bug 1300464 for me? it was ok'ed by infinity and cjwatson in -release