[01:08] <cnd> RAOF, I'm about to upload xorg-gtest 0.2.0 to precise (\o/)
[01:08] <RAOF> Wooo!
[01:08] <cnd> I now have no reservations about the MIR
[01:09] <RAOF> I'll address the final gtest MIR comment today.
[01:09] <cnd> RAOF, oh, I didn't notice any MIR comments for gtest
[01:09] <cnd> RAOF, do you have the bug #?
[01:09] <RAOF> https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/949575
[01:09] <RAOF> Just to run the tests during the build.
[01:12] <cnd> doh, I need to change libxorg-gtest-dev from arch any to arch all
[01:47] <Sarvatt> multiarch certainly made local testing annoying, purging all my humble bundle games every time i want to test local libdrm/mesa builds without using a ppa :)
[01:47] <Sarvatt> since i dont have :i386 versions built too
[01:48]  * Sarvatt starts not caring about making .deb's of upstream crap he tests
[01:50]  * RAOF just builds i386 versions, too.
[01:57] <Sarvatt> oh thats a blast with mesa on laptops
[02:06] <Sarvatt> would be nicer if we didn't support 8 and 16 bit versions of osmesa to cut the build time in half though :)
[02:07] <cnd> RAOF, ok, finally got xorg-gtest uploaded after needing a few more changes
[02:07] <RAOF> Wootness.
[09:26] <tjaalton> hmm, want an intuos5S, the intuos4L is too big
[09:26] <tjaalton> driver support missing, will add it
[15:17] <Sarvatt> bryceh: i'm so confused about https://launchpad.net/ubuntu/+source/mesa/7.11-0ubuntu3.1 -- you added an intel patch instead of the nouveau fix? :P
[15:40] <Sarvatt> bryceh, RAOF: we have to be super careful with intel cherry-picks in mesa now, the symlinks are dereferenced for the tarballs so when we add a patch touching src/mesa/drivers/dri/intel/* it has to be duplicated out to the other places like src/mesa/drivers/dri/i965
[16:45] <Prf_Jakob> Sarvatt: symlink derefes sounds like a bug.
[16:45] <Prf_Jakob> Sarvatt: I'll do the release today btw.
[16:45] <Prf_Jakob> As soon as I get a review on a patch.
[16:45] <tjaalton> it's different in 8.0
[16:45] <Prf_Jakob> Ah ok
[16:46] <tjaalton> i guess the tarball has the same symlinks
[16:46] <tjaalton> whereas 7.11 didn't, so we had to do tricks in order to build a source package from git
[16:47] <tjaalton> since dpkg-source refuses to work if a real file changed to a symlink
[17:04] <ricotz> tjaalton, hi
[17:07] <tjaalton> ricotz: yo
[17:08] <ricotz> tjaalton, the #debian-gnome guy really hoping for libwacom soon ;) they are already doing gnome 3.3/3.4
[17:09] <tjaalton> ricotz: and ready to sponsor it?
[17:09] <ricotz> yeah, mbiebl would upload it
[17:09] <bryceh> Sarvatt, actually, looks like I got two bugs transposed.
[17:10] <tjaalton> ricotz: so you filed the ITP?
[17:10] <ricotz> tjaalton, you want to join #debian-gnome
[17:10] <tjaalton> oh I do? :)
[17:10] <ricotz> tjaalton, no, i havent
[17:10] <tjaalton> what's 659700 then
[17:11] <Sarvatt> bryceh: i'm in the process of working up a SRU for https://launchpad.net/~sarvatt/+archive/sru6 , is it ok if I just remove it from this one? this one will be verified really fast even though its large, its affecting every ivybridge system QA is running tests against
[17:11] <tjaalton> oh it was me
[17:11] <tjaalton> hehe
[17:11] <ricotz> ;)
[17:11] <bryceh> Sarvatt, that's fine
[17:15] <Sarvatt> bryceh: that patch you added for src/mesa/drivers/dri/intel needs to be duplicated into src/mesa/drivers/dri/i965 and src/mesa/drivers/dri/i915 if appropriate to get used though
[17:15] <Sarvatt> because of that symlink problem in 7.11
[17:16] <bryceh> Sarvatt, right, but I'm not sure the patch should be sru'd
[17:17] <bryceh> Sarvatt, it's for 757906, whose oneiric task is set to wontfix
[17:30] <bryceh> mm, think maybe it shouldn't have been set to wontfix though.
[19:29] <Sarvatt> hmm our mesa debs are .gz
[19:29] <Sarvatt> we used lzma for 7.11
[19:30] <Sarvatt>         dh_builddeb -s -- -Zlzma
[19:30] <Sarvatt> vs
[19:30] <Sarvatt>         dh_builddeb $(foreach pkg,$(dbgpkg),-p$(pkg)) -- -Zxz
[19:30] <Sarvatt>         dh_builddeb $(foreach pkg,$(otherpkg),-p$(pkg))
[19:33] <Sarvatt> that might explain the lack of size difference even though all the dri1 stuff was dropped back when i compared it
[19:47] <Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 2.9M Mar 20 15:46 data.tar.xz
[19:47] <Sarvatt> -rw-r--r--  1 sarvatt sarvatt 5.5M Mar 20 15:28 data.tar.gz
[19:47] <Sarvatt> thats a huge chunk of livecd space
[19:48] <Sarvatt> just for libgl1-mesa-dri
[19:49] <Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 2.9M Mar 20 15:48 data.tar.lzma
[19:51] <Sarvatt> so lzma that doesnt need a pre-depends diff for every package, or xz which does? :P
[19:52] <albert23> does deb compression matter on a live cd, as the package is installed?
[19:55] <Sarvatt> good point, dont think it does outside of alternate, i've just always gone under the impression that the compressed deb size is how much approximately is going to be used there but that doesn't make sense :)
[21:44] <bryceh> should we be thinking about pulling in the libX11 1.5 release with keith's fix for those xcb sync bugs?
[21:46] <tjaalton> sure, better than a beta
[21:46] <tjaalton> or rc
[21:57] <RAOF> Yeah, probably a good idea.
[21:57] <bryceh> would likely make seb128 happy
[21:58] <seb128> \o/
[21:58] <seb128> that would be great
[21:59] <seb128> would that fix all the XAlloc assert bugs?
[21:59] <seb128> _XAllocID
[21:59] <bryceh> seb128, it may; it's not widely tested yet tho afaict
[22:00] <FernandoMiguel> Olá
[22:02] <bryceh> seb128, technically I think the bugs are caused by client apps that are using libxcb in non-threadsafe ways
[22:02] <mlankhorst> probably
[22:02] <bryceh> seb128, libxcb is advertised as a single-threaded lib, so when multi-threaded clients use it, they have to be careful.
[22:02] <bryceh> seb128, so I'm not sure if keith's patch is a true fix or may be just papering over bad client coding.
[22:03] <bryceh> but... if it stops the asserts...
[22:03] <seb128> bryceh, I doubt any "client" use xcb
[22:03] <seb128> but maybe a gtk or cairo bug...
[22:03] <jcristau> err
[22:03] <bryceh> seb128, well, they do via libx11
[22:03] <seb128> like "use it directly"
[22:04] <bryceh> ah, right
[22:04] <seb128> bryceh, they use gtk,cairo
[22:04] <jcristau> using libxcb in a multi-threaded app is very much ok.
[22:04] <RAOF> xcb is lovingly threadsafe, what with all the cookies and all.
[22:05] <bryceh> seb128, also fwiw where we've seen this in other apps (there was one in apport a few weeks back), the issue was able to be resolved in the client itself.
[22:05] <RAOF> Doesn't Keith's patch fix a deadlock in libx11?  I'm not sure that's hugely likely to fix the XAllocID asserts.  But it might, things are madness.
[22:06] <jcristau> RAOF: it does.
[22:06] <jcristau> (only fix a deadlock)
[22:07] <RAOF> Which is certainly a fix we want; deadlocking apps isn't exactly brilliant behaviour :)
[22:07] <bryceh> ok, so seb128 go back to being sad
[22:08] <seb128> :-(
[22:08] <mlankhorst> :-o
[22:08] <jcristau> does seb128 have a reproducer for his bug?
[22:09] <bryceh> bug #950222
[22:10] <jcristau> closed worksforme :)
[22:10] <seb128> jcristau, no, we just get hundred of XAllocID assert in random GNOME component and I've no clue what info would be useful since they seem random, no user come with a way to trigger them
[22:11] <seb128> jcristau, bug #905686
[22:11] <seb128> bug #507062
[22:11] <seb128> jcristau, so bug got so dupped you can't open them without getting launchpad to timeout half the time
[22:13] <tjaalton> there was one bug that looked similar which was a flaw in glib
[22:13] <tjaalton> fixed last fall i think
[22:15] <jcristau> it's breaking single threaded apps?
[22:16] <jcristau> looks like https://launchpadlibrarian.net/37855577/ThreadStacktrace.txt only has 1 thread
[22:18] <bryceh> seb128, I think a lot of those shouldn't have been all duped together.  Just because they trigger the same assert doesn't mean it's the same bug.
[22:21] <seb128> bryceh, I would be glad to have any clue how to figure that, what to do with them
[22:22] <bryceh> seb128, well what I do is look in libx11:src/xcb_io.c and grep for the assertion that the bug hit.
[22:22] <bryceh> seb128, often times the XCB guys have left comments explaining what the assertion means
[22:23] <bryceh> seb128, and for many of these bugs, that reveals a coding error somewhere in the client
[22:25] <bryceh> jcristau and RAOF said above that xcb works fine in multithreaded apps, but from all the bugs you and I have seen where xcb assertions get tripped, it seems very sensitive to threading issues in clients.
[22:25] <jcristau> these asserts are in xlib
[22:25] <jcristau> not xcb
[22:26] <bryceh>  __assert_fail_base (fmt=0xb75b1698 <Address 0xb75b1698 out of bounds>, assertion=0x76ad79 "ret != inval_id", file=0x76acea "../../src/xcb_io.c", line=528, function=0x76adfe "_XAllocID") at assert.c:94
[22:26] <bryceh> jcristau, xcb_io.c is not xcb?
[22:26] <jcristau> that's in xlib
[22:28] <bryceh> jcristau, yes, in libx11:src/xcb_io.c like I said
[22:28] <seb128> those XAllocID assert a probably the number 1 bug we get through desktop
[22:28] <seb128> and I've no clue what's the issue or how to debug it
[22:28] <seb128> and it's clients apps all being buggy, or gtk, or x11 or whatever
[22:34] <bryceh> seb128, do you see the issue as being random, or do you know of reliable ways to reproduce it?
[22:34] <bryceh> it/them?
[22:34] <RAOF> Whoopsie doesn't yet have any ability to do fancy client stuff yet, does it?
[22:34] <seb128> bryceh, random, I never hit those bugs
[22:35] <bryceh> seb128, I've hit one once, but never reproduced.
[22:36] <Sarvatt> they're all drawing theme stuff after an app crash while using murrine or clearlooks from a quick look at the bug reports across the other distros
[22:36] <bryceh> seb128, that particular instance I believe was when I was in the middle of upgrading stuff, and wondered if it might have been due to an underlying library getting changed out.
[22:36] <Sarvatt> maybe we only notice it more because of ambiance? :)
[22:37] <seb128> Sarvatt, could be
[22:39] <seb128> then you have bugs like bug #948089
[22:39] <seb128> assert !xcb_xlib_threads_sequence_lost
[22:39] <seb128> I'm pretty sure that one happens when the session doesn't close properly
[22:39] <seb128> i.e gnome-session or xorg segfault
[22:40] <seb128> I wonder if the XAllocID one is a similar red herring
[22:44] <RAOF> Entirely possible.
[22:48] <seb128> bryceh, RAOF: what about bug #926379
[22:48] <seb128> that got enough dups that launchpad timeout to open it
[22:50] <bryceh> seb128, it's unrelated to the assert bugs.  There's a patch to add logging, which has been run and given, so waiting on upstream for a fix
[22:51] <bryceh> seb128, a few more folks testing that and providing logs might help
[22:51] <seb128> bryceh, yeah, I know it's not related to the assert, but that one is concerning because it keeps collecting dups every day on unity
[22:51] <seb128> ok
[22:51] <seb128> so "needs info"
[22:52] <seb128> that seemed like something we should tackle for beta2
[22:53] <bryceh> yeah
[22:56] <bryceh> seb128, I guess the thing blocking it currently is that it's hard to reproduce synthetically
[22:56] <bryceh> or I should say, developers haven't reproduced it synthetically
[22:57] <RAOF> None of us have been able to reproduce it, have we?
[22:58] <Sarvatt> never
[22:58] <RAOF> Because this would sound like a job for apitrace™, even though the actual windows would be blank.
[22:59] <Sarvatt> oh the mesa bug
[22:59] <RAOF> Yeah, the mesa bug.
[22:59] <Sarvatt> sorry, i just popped back on for a minute and thought people were talking about the _XAllocID assert
[22:59] <RAOF> Nope :)
[23:00] <bryceh> Sarvatt, seb128 advanced the topic ;-)
[23:00] <Sarvatt> tjaalton said he hit that one
[23:01] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=46739
[23:22] <cnd> bryceh, I was promised warmer weather this time of year... :(
[23:23] <Sarvatt> cnd: lets trade, too freaking hot
[23:23] <cnd> Sarvatt, fine by me :)
[23:23] <cnd> Sarvatt, what have your highs been?
[23:24] <Sarvatt> 87 yesterday
[23:24] <cnd> wow
[23:24] <Sarvatt> 75 or 80 today, im not sure
[23:24] <cnd> Sarvatt, you've seen the temperature map of the US, right?
[23:25] <Sarvatt> i'm jealous every time i look at the portland weather in the indicator
[23:25] <Sarvatt> rain rain rain rain rain snow snow rain snow rain snow, highs in the 40's :P
[23:25] <cnd> I hope you're not serious...
[23:25] <Sarvatt> 100%
[23:26] <bryceh> cnd, heh who promised you nice weather in Portland in March?
[23:26] <cnd> bryceh, no one promised nice weather, but this is awful
[23:26] <cnd> this would be understandable in january
[23:26] <bryceh> cnd, yep.  March is the worst in portland
[23:26] <cnd> but not in spring
[23:26] <cnd> and I'm fine with the rain
[23:26] <cnd> it's just these frigid temperatures
[23:26] <Sarvatt> cnd: where did you move from?
[23:27] <cnd> Sarvatt, columbus, oh
[23:27] <bryceh> the snow is a bit unusual, but depressing rain is all about March in portland
[23:27] <cnd> meh, rain is fine
[23:27] <cnd> if it were in the 50s or 60s I'd have no complaints
[23:27] <bryceh> s/depressing/depressing and cold/
[23:28] <bryceh> in grade school and middle school I used to have to walk to piano lessons and home in this weather (~2 miles).
[23:28] <bryceh> builds character (and makes you want to own a car)
[23:28] <cnd> heh
[23:29] <bryceh> cnd, it'll turn around come april.  We probably won't get "nice" days until May tho
[23:29] <cnd> cool
[23:29] <cnd> well, we're not too far from april :)
[23:29] <bryceh> yep
[23:30] <bryceh> in May, this thing people call  "the Sun" sometimes shows up.  Usually high up in the sky.  Keep an eye out for it.
[23:30] <Sarvatt> my office is like 15 degrees warmer than the rest of the house and hot even with the ac blasting, thats why i'm jealous :)
[23:31] <bryceh> Sarvatt, I can turn every computer on in my office right now, and not get roasted out
[23:31] <bryceh> I can even put on t he projectors, but then I do need to crack a window
[23:32]  * RAOF drops off his car for a service.


[17:03] <tseliot> mamarley, ricotz: I've just uploaded 352 and 352-updates in xenial. The diff should be zero now (I hope)
[17:04] <ricotz> tseliot, thanks!
[17:04] <tseliot> :)


[19:25] <bobweaver> ping tgm4883  i finally got the themes down last night. I also see that there was a update in the theme for mythbuntu that broke some things. I do not want to have to keep up with the xml files the more that I test this
[19:26] <bobweaver> so this is what I am thinking. I am going to write a sdk kit for myth tv that uses the backend that is there. Seems like there has been alot of work with qt5 so looks like I might be able to take the stuff that they have been user backend stuff and make qml elements for it
[22:36] <tgm4883> bobweaver, check your email, you should have a new SD coupon
[22:36] <bobweaver> ??
[22:37] <tgm4883> bobweaver, Schedules Direct
[22:37] <tgm4883> bobweaver, from superm1
[22:37] <bobweaver> Sweet !
[22:37] <tgm4883> bobweaver, May-June is when we get ours and distribute to the mythbuntu team
[22:38] <bobweaver> tgm I am making a new plugin for upstream that is reads all the libs and ,akes qml plugins for it
[22:38] <bobweaver>  I am having tins of fun lol
[22:38] <tgm4883> cool
[22:45] <bobweaver> tgm4883,  is superm1 the same dude I meet at uds that you introduced to me ?
[22:45] <tgm4883> hmm
[22:45] <tgm4883> bobweaver, possibly
[22:45] <tgm4883> he was my roommate, so it's probably him
[22:45] <bobweaver> what I am doing right now is taking alot of time
[22:46] <bobweaver> super simple data entry almost
[22:47] <bobweaver>  #include "../libmythtv/someheader.h"     then go and register it             qmlRegisterType<SomeHeader>
[22:48] <bobweaver> #include "../libmythui/AppleRemote.h"      qmlRegisterType<AppleRemote>
[22:48] <bobweaver> ect ect
[22:49] <bobweaver> or more like     qmlRegisterType<AppleRemote>(uri, 1, 0, "AppleRemote");


[08:51] <shadeslayer> hi, we're trying to backport KDE to Precise and have used the backported HWE stack from raring, however, it seems like the window manager still depends on libgl1-mesa-glx because https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/mesa-lts-raring/precise-updates/view/head:/debian/libgl1-mesa-glx-lts-raring.shlibs still says libgl1-mesa-glx instead of the -lts-raring package, is this intentional?
[08:51] <shadeslayer> if not, should we still build using the regular stack but ask our users to manually install the LTS stack
[08:52] <shadeslayer> s/not/so/
[09:01] <RAOF> shadeslayer: Deliberate
[09:01] <shadeslayer> but then dpkg-shlibdeps adds the wrong dependency?
[09:02] <RAOF> shadeslayer: Because the ABI for libgl1-mesa-glx is the linux OpenGL ABI, so really everything *actually* depends on the libgl1 branch of that dependency; the libgl1-mesa-glx branch is to help apt out.
[09:04] <shadeslayer> yofel: ^^
[09:04] <RAOF> shadeslayer: Why does the KDE backport require the HWE backport stack?
[09:05] <yofel> well, the reason we're doing that because KDE upstream doesn't support any configurations they don't test (at least Martin Gräßlin doesn't). That includes KDE 4.11 with mesa 8
[09:05] <shadeslayer> RAOF: upstream told us that anything using old mesa versions is unsupported, only the latest mesa is supported because there could be problems during runtime
[09:05] <yofel> so we're *trying* to make kde 4.11 pull mesa9 in, but apt isn't really making that easy
[09:05] <shadeslayer> ^^
[09:06] <RAOF> Hm.
[09:06] <RAOF> You should be able to add a manual dependency on the various bits.
[09:07] <RAOF> But I don't think installing the lts-raring stack on an existing system is something we've tried to support very hard.
[09:07] <yofel> is there an easy way to do that with an shlibdeps rule? or only by manually adding it in control
[09:07] <RAOF> It's expected that if you've got a working install, then you don't need the backport stack for hardware enablement ☺
[09:07] <RAOF> mlankhorst would be the resident expert here.
[09:08] <shadeslayer> would adding manually to control even work?
[09:08] <RAOF> You *could* do it with a local shlibs file, I think, but I'm not sure why you'd want to do that instead of just a manual dependency in debian/control
[09:08] <yofel> it would, libgl1-mesa-glx would be overriden by libgl1
[09:08] <mlankhorst> erm I don't think depending on a version would work in the lts
[09:09] <yofel> why not?
[09:10] <mlankhorst> because the user might use the blob drivers for example, in which case mesa version wouldn't matter, if you use the lts stack libgl1-mesa-glx is virtual, which means versioned depends would fail
[09:11] <yofel> well, so far we don't have versioned depends, but we try to directly pull in the -lts-raring stack
[09:11] <yofel> which ended up causing a dependency mess
[09:11] <mlankhorst> it's not recommended to do that either
[09:11] <mlankhorst> best you can do is request the user to do that upgrade
[09:15] <mlankhorst> on amd64 it requires apt-get install xserver-xorg-lts-raring libgl1-mesa-{dri,glx}-lts-raring:i386 , I guess we need to review this in the next lts, maybe allow mesa to be separately upgraded
[09:16] <yofel> why i386 o.O?
[09:17] <mlankhorst> because of steam/wine/ other 32-bits applications that may depend on libgl
[09:17] <yofel> ok, good point
[17:56] <MercX> I am having an issue with my ubuntu 12.04 installation


[12:14] <BluesKaj> Hi all
 hey, i m using wayland, but i have problem
 whenever i go full screen on any browser or video player , there is a vertical white line on right side of the screen
[16:13] <Oderus> hi. having an issue where i have a top panel and a couple of plasmoids on my desktop that i keep removing over and over but after each reboot they come back
[16:23] <diogenes_Vx15> Oderus, you probably have to setup your system to always start with a new session.
[16:24] <Oderus> diogenes_Vx15: i will try that
[16:24] <Oderus> will let you know, rebooting
[16:25] <diogenes_Vx15> ok
[16:30] <Oderus> unfortunately no dice. i tried kquitapp5 plasmashell too after removing said items, and then re-running plasmashell and it still puts them back
[16:41] <Oderus> think i found the config file


[01:32] <jrwren> I ask about DD because ZOMG this usrmerge thread.
[02:00] <dzho> how bad is it, on a scale of one to systemd ?
[02:04] <dzho> ;-)
[02:53] <jrwren> about the same, honestly.
[02:54] <jrwren> and of course, systemd is like its own kind of godwin's law in the debian world. Maybe we should call this Lennart's law.
[03:39] <cmaloney> I think Lennart's Law is a thing
[21:55] <cmaloney> Afternoon / Evening
[22:20] <_stink_> yes
[22:28] <cmaloney> heh


[05:35] <kickinz1> infinity, I updated the bug page with the new debdiff and new build logs. Quick tests work also on arm64, thanks!
[05:36] <kickinz1> infinity bug: 1430760
[10:54] <infinity> kickinz1: Looks good.
[10:55] <rbasak> infinity: happy for me to sponsor? Could you approve the FFe in the bug now please?
[10:57] <infinity> rbasak: Go for it.
[10:57] <infinity> rbasak: Happy to see it got smoketested on arm64 too, and my patch actually works. :P
[10:58] <infinity> rbasak: If 1.6 doesn't already contain such a patch (I didn't look), I hope someone will take care to forward it on my behalf, since my love for docker is in the negative? :P
[10:58] <rbasak> kickinz1: could you please send infinity's patch upstream?
[11:07] <infinity> kickinz1: Actually, scratch that, I'll submit a github PR for it.
[12:04] <kickinz1> infinity, rbasak read, I'll let infinity do its PR.
[12:08] <infinity> kickinz1: powerpc might need a similar fix, testing that too.
[12:09] <kickinz1> infinity, thanks, I don't have access to any powerpc host for now. I'll check again if I can access porterboxes.
[12:29] <infinity> kickinz1: Huh.  And while looking at this, I noticed armhf is actually broken too.  I wonder how it works. :P
[12:29] <kickinz1> infinity: I have it working on cloud.online.net
[12:30] <kickinz1> infinity: Do you want access to it ?
[12:31] <infinity> kickinz1: What kernel version is it running on?
[12:31] <kickinz1> some custom 3.19-aufs, let me check precisely.
[12:32] <kickinz1> Linux scw-158f0c 3.19.1-181 #1 SMP Thu Mar 12 15:57:27 UTC 2015 armv7l armv7l armv7l GNU/Linux
[12:33] <kickinz1> infinity, I did my work on this to get better perf than on beagleBoard.
[12:33] <infinity> Hrm.  Well, setns will be failing on that setup.
[12:34] <infinity> The upstream code is off-by-one.
[12:34] <kickinz1> infinity<EMAIL_ADDRESS>I imported you ssh key.
[12:34] <kickinz1> infinity, I use byobu.
[12:37] <kickinz1> infinity, ^that was if you wanted to check.
[13:43] <flexiondotorg> infinity, Could you update the ubuntu-mate-meta package for me please?
[13:43] <flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1441728
[13:49] <infinity> flexiondotorg: Running the update thingee.
[13:50] <flexiondotorg> infinity, Thanks :)
[13:55] <flexiondotorg> infinity, Are you in the position to take a peek at something else for me?
[13:55] <infinity> flexiondotorg: Maybe, depends on the thing.
[13:56] <flexiondotorg> infinity, In the PPA you'll see indicator-application-gtk2 which is patched for MATE.
[13:56] <flexiondotorg> https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/vivid-mate
[13:57] <flexiondotorg> infinity, Here is the code with my patch - https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2
[13:57] <flexiondotorg> infinity, Here is the Approved merge proposal - https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116
[13:58] <flexiondotorg> infinity, However. I can get the package to build in a PPA. But in what whatever your devs use to build packages it failed.
[13:58] <flexiondotorg> infinity, I can't reproduce that build fail.
[13:58] <flexiondotorg> infinity, Help? ;)
[14:03] <infinity> flexiondotorg: Before we worry about the testsuite failure, has this been passed by the lubuntu people?  This ships on their desktop as well.
[14:04] <flexiondotorg> infinity, Well, I tested lubuntu. No issues. I couldn't raise anyone on the lubuntu team to test and confirm.
[14:22] <infinity> flexiondotorg: Does this look sane: http://paste.ubuntu.com/10782997/
[14:22]  * flexiondotorg looking...
[14:25]  * infinity isn't sure why update.log isn't getting cleaned...
[14:25] <flexiondotorg> infinity, Those look right to me. Other than perhaps I should add [!powerpc] to grub-pc in the live seed.
[14:26] <flexiondotorg> infinity, The other changes are what cjwatson has helped me with a couple of weeks back.
[14:26] <infinity> flexiondotorg: grub-pc doesn't exist on powerpc, that would be a no-op.
[14:26] <flexiondotorg> infinity, OK.
[14:26] <flexiondotorg> infinity, Then looks like what I expected. All recent changes have been to fix bugs.
[14:29] <infinity> flexiondotorg: Okay, uploaded.
[14:29] <flexiondotorg> infinity, Many thanks.
[14:30] <infinity> flexiondotorg: As for the indicator thing, I can't reproduce the test suie failure.  I'm mildly concerned about what happens if both indicator-application packages are installed at the same time, but if you claim it doesn't break, then alright...
[14:30] <flexiondotorg> infinity, Thanks for checking the build.
[15:14] <slangasek> ^^ would appreciate if someone could review this cloud-init package (I uploaded)
[15:17] <infinity> slangasek: Can't, I'm in a meeting.
[15:17] <infinity> :P
[15:17] <slangasek> infinity: pff blow off the meeting this is more important
[15:18] <infinity> slangasek: What did you do to the changelog?
[15:18] <slangasek> infinity: oh shoot, what did I do?
[15:18] <infinity> slangasek: And the changes it referenced...
[15:18] <slangasek> I may have not re-checked the changelog
[15:19]  * infinity hands slangasek an "always debdiff before upload" lapel pin.
[15:19] <slangasek> infinity: the bzr branch was up-to-date and debdiff is for old people
[15:20] <infinity> slangasek: You still trust the bzr branches?  That's so cute.
[15:20] <slangasek> when it's up to date, yes :P
[15:20] <infinity> Clearly it wasn't actually. :P
[15:20] <infinity> You were lied to!
[15:23] <slangasek> infinity: right, so one person committed changes to the bzr branch and the other didn't, /lovely/


[14:50] <GridCube> hello, there is a spamer/flooder on #ubuntu-es-cafe
[14:50] <GridCube> called ojitos
[14:51] <Myrtti> and how does he spam exactly?
[14:52] <GridCube> random nonsense and vowels
[14:52] <GridCube> i would call m4v but he seems away
[14:54] <GridCube> he seems to have calm down, sorry for bothering you
[14:54] <Myrtti> it happens when someone with ability to kick and ban appears
[15:02] <Myrtti> m4v, funkyHat, Pici, AlanBell, topyli: FYI used banhammer on ojitos as the attempts of the channel regulars on catalysing seemed to yield no results. Sorry for budging in, please remove the ban at leisure.
[15:52] <m4v> Myrtti: no need to sorry, thanks for intervening.