[00:03] <bschaefer> mterry, i've filed a FFe, so lets just leave it out of trunk for now
[00:03] <hasselmm> mhall119, Saviq: well. new plan. instead of ranting, try to get UnityNext running on wayland :-D
[00:03] <bschaefer> mterry, thanks!
[00:03] <hasselmm> mhall119, Saviq: is there public code already?
[00:06] <mhall119> hasselmm: you mean on weston, or make Mir fluent in the Wayland protocol?
[00:07] <mhall119> hasselmm: public code for what?
[00:08] <mhall119> FWIW, I like this new plan better :)
[00:10] <hasselmm> mhall119: well. raof said weston and its protocols don't fit at all. so i expect things to end somewhere in the middle between wayland core and weston.
[00:10] <mhall119> so do you want mir code or Unity code?
[00:11] <hasselmm> mhall119, the unity branch that's supposed to run on top of mir
[00:11] <mhall119> I think https://launchpad.net/unity/phablet is the closest thing to that atm, as we re-org around one converged codebase
[00:12] <hasselmm> ok. thank you.
[00:13] <mhall119> np
[00:14] <mhall119> happy hacking
[00:16] <hasselmm> well. for now good night. (stupid early daily scrums... kills all hacker romance)
[04:32] <TheMuso> Does Qt provide any framework for sound events, i.e incoming phone call/message etc? If not, we should look at tying in libcanberra via QML/Qt bindings.
[04:39] <TheMuso> Quick check of stuff in Ubuntu says that KDE uses it, but not Qt.
[08:58] <sil2100> didrocks: hello! Are the jenkins autopilot builders still down?
[08:58] <didrocks> sil2100: it seems so…
[08:58] <sil2100> didrocks: since I see the ps-indicators-autopilot-release-testing job waiting for autopilot-nvidia ;/
[08:58] <didrocks> sil2100: veebers told me he would see with mmrazik
[08:58] <didrocks> mmrazik: any news? were you pinged on that?
[08:59] <mmrazik> didrocks: I was. Wasn't it the discussion you had with gema on #qa?
[08:59] <mmrazik> didrocks: srry. I had an impression they are aware and we are waiting for jcollado.
[08:59] <mmrazik> let me check
[09:00] <mmrazik> oh... I see. the problem is something else then wha tI thouhgt
[09:00] <didrocks> mmrazik: TBH, nothing is running atm on the machine
[09:00] <didrocks> mmrazik: can't we shutdown jenkins?
[09:00] <didrocks> and restart it
[09:01] <mmrazik> didrocks: nothing running on magners you mean?
[09:01] <didrocks> mmrazik: yeah
[09:01] <didrocks> well, only the stuck job :p
[09:01] <mmrazik> didrocks: I don't know TBH. I might be able to fix the autopilot machines and I don't really want to restart jenkins where I'm onlye "guest"
[09:01] <mmrazik> didrocks: jibel is on vacation, right?
[09:01] <didrocks> mmrazik: right, he is
[09:02] <didrocks> mmrazik: do you mind coordinating with #qa?
[09:02] <didrocks> mmrazik: then, we can relaunch the daily, that's not an issue
[09:02] <mmrazik> didrocks: I'm not sure a restart will help anyway. The problem is some of the nodes are offline
[09:02] <mmrazik> we just need to bring them online again
[09:03] <mmrazik> restarting just jenkins most likely is not going to help with these
[09:04] <didrocks> mmrazik: what's the node?
[09:04] <didrocks> mmrazik: the machine is working
[09:04] <didrocks> isn't the node attached to the jenkins instance?
[09:04] <mmrazik> didrocks: magners. For some reason it fails to authenticate. It looks like its authenticating with jibels credentials.
[09:05] <didrocks> interesting…
[09:10] <mmrazik> didrocks: AFAICS the configuration of the slaves got corrupted
[09:10] <mmrazik> fixing it
[09:11] <didrocks> mmrazik: \o/ thanks
[09:12] <sil2100> \o/
[09:14] <mmrazik> sil2100, didrocks, veebers: they should be all up
[09:14] <didrocks> ok
[09:14] <mmrazik> going to write jibel an e-mail as I don't know what the original configuration was...
[09:14] <sil2100> Excellent! Thanks
[09:14] <didrocks> let me try restarting indicators
[09:14] <didrocks> thanks mmrazik :)
[09:14] <mmrazik> didrocks: they are building
[09:14] <didrocks> mmrazik: oh great :)
[09:14] <mmrazik> didrocks: they were queued
[09:14] <mmrazik> just the machines were not online so the jobs were waiting
[09:15] <didrocks> mmrazik: ok, perfect, thanks!
[09:15]  * sil2100 wants to use the indicators job to nasty experiments later
[09:17] <didrocks> sil2100: so I confirm the issue btw
[09:17] <didrocks> sil2100: fresh session, first super + A doesn't work
[09:18] <didrocks> sil2100: what we can do is workaround for now, like press super, then super + A in this test
[09:18] <didrocks> sil2100: and having a separate test for Super + A :)
[09:19] <sil2100> didrocks: yes, well, I discussed that with andyrock yesterday, but we're still not sure if it's the same issue - and what's the cause of it
[09:19] <didrocks> sil2100: I think we need a separate test for super + A anyway, but ok, good hunting! :-)
[09:19] <sil2100> didrocks: since ok, indeed the first super+a does not work as I noticed yesterday, but the dash is being opened many times before the test already
[09:20] <didrocks> sil2100: ah ok
[09:20] <sil2100> didrocks: I think indeed we'll have to workaround this breakage anyway for now ;p
[09:20] <didrocks> so not that one maybe in this case :)
[09:20] <didrocks> sil2100: yeah :/
[09:49] <sil2100> hmmmm
[09:52] <sil2100> No idea what's happening, now I can't even reproduce that 'first super+a on a clean session does not work' bug - even though I have not upgraded anything!
[09:52] <sil2100> Still, for future reference:
[09:52] <sil2100> https://bugs.launchpad.net/unity/+bug/1152517
[09:52] <sil2100> And I'll anyway workaround the problem, since it's still failing on jenkins
[10:32] <didrocks> sil2100: you have new test results
[11:06] <MCR1> So you are not interested in Compiz fixes anymore and want contributors to go away so you have full control ? Or what is the reason for making those stupid Compiz changes ? Do I have to beg you twice now per fix to accept it, so your users won't experience bugs anymore ?
[11:07] <MCR1> I am pretty pissed as contributor... and I will not accept the death of Compiz because of Canonical policies...
[11:09] <MCR1> ignorance is bliss ?
[11:11] <sil2100> didrocks: testing the workaround in a jenkins environment right now ;)
[11:11] <didrocks> sil2100: hum, using the jobs?
[11:11] <didrocks> sil2100: or something else?
[11:11] <didrocks> sil2100: I would want to finish waiting on unity to publish first if possible :)
[11:12] <sil2100> didrocks: veebers has a fun job called autopilot-run-custom-branch on another jenkins which can be used for building given tests from given branches ;)
[11:13] <didrocks> ok :)
[11:36] <sonne> greetings!
[11:38] <sonne> reading the shopping lens source code for ringtail, i see that the https handling is delegated to the vala libraries... i'm wondering how strict is their certificate authenticity check, anyone knows about it?
[11:41] <sil2100> veebers: ping!
[11:42] <sil2100> sonne: hello, maybe pstolowski would know more?
[11:42] <sonne> sil2100, i've been suggested to ask him actually... :)
[11:43] <pstolowski> sonne, sil2100: no idea, sorry, you may want to check how the handle ssl_strict flag there... mhr3?
[11:44] <mhr3> sonne, all i know is that our security team is happy with it
[11:44] <mhr3> mdeslaur, ^
[11:44] <sil2100> ;)
[11:45] <mhr3> sonne, also, it's no "vala libraries" it's standard libsoup
[11:46] <sonne> mhr3, you may have noticed that my vala knowledge is nowhere beyond "vala is a language"... forgive my imprecision there :)
[11:47] <mhr3> sonne, just so you don't think that we have our own very special https implementation
[11:47] <sonne> mhr3, that's a good point
[11:47] <sonne> i thought there was some kind of stdlib, like there is in other languages...
[11:57] <sonne> mhr3, pstolowski, in case you're interested: i checked libsoup and it creates strict https connections by default :)
[12:11] <didrocks> Trevinho: hey, I'm seeing an interesting bug
[12:11] <didrocks> Trevinho: maximize a window
[12:11] <didrocks> you have a one pixel "free" on the the edge
[12:11] <didrocks> (like if it's chromium, you can't scroll for instance)
[12:11] <didrocks> if you have an application behind
[12:11] <didrocks> this one will become focused
[12:38] <mdeslaur> sonne, mhr3: the lens does set ssl_use_system_ca_file and ssl_strict. If you suspect there's an issue, please file a security bug, and we'll take a look.
[12:53] <om26er> where can i get libbamf3-0 0.4.0 ??
[12:58] <om26er> didrocks, you might know ? ^^
[12:59] <didrocks> om26er: are you using raring?
[12:59] <didrocks> raring has  0.4.0daily13.03.07-0ubuntu1
[12:59] <om26er> didrocks, its quantal, i am installing qml-phone-shell and it seem to require that version
[12:59] <didrocks> om26er: not sure about the qml-phone-shell on quantal though
[12:59] <didrocks> because to ask on #ubuntu-phone
[13:00] <om26er> didrocks, i'll just download the raring daily and try there then
[13:24] <om26er> why is autolanding on compiz not working ?
[13:25] <sil2100> om26er: for which branch?
[13:25] <om26er> sil2100, https://code.launchpad.net/~mc-return/compiz/compiz0.9.9.merge-plugin-freewins/+merge/150960
[13:25] <om26er> or this as well https://code.launchpad.net/~brandontschaefer/compiz/lp.1075207-fix-ubuntu-super-p-patch/+merge/151079
[13:26] <sil2100> Maybe the merger got moved to lp:compiz/raring and it's no longer enabled for lp:compiz? hmmm, fginther ^ ?
[13:28] <fginther> sil2100, yes, the auto-merge was moved to lp:compiz/raring
[13:28] <om26er> ah
[13:30] <sil2100> fginther: morning!
[13:30] <sil2100> :)
[13:30] <fginther> sil2100, good morning
[13:31] <luv> hi again
[13:31] <luv> I asked where to get in touch with ubuntu online accounts devs
[13:32] <luv> and was pointed here (?)
[13:32] <didrocks> mardy: ^
[13:32] <mardy> luv: hi! I'm one of them :-)
[13:33] <luv> great
[13:33] <luv> I would like to add a feature to log out (that is not just disable/enable an account) but discard the token and all so a new login is required
[13:33] <luv> kinda regression not having this feature in but patching apps to use UOA instead of they auth mechanism (because the apps usually support logouts)
[13:34] <luv> obviously not for raring, though sounds like something you would be interested in merging?
[13:35] <mardy> luv: yes, definitely
[13:35] <mardy> luv: discarding the token is something definitely possible (at the framework level), but forcing the logout is more complicated
[13:36] <mardy> luv: do you intendo to do so that when the logout button is pressed, all applications using the account immediately stop using it?
[13:37] <luv> well, that sounds ideal, though i wouldn't really mind personally closing an app explicitly after logging out (I use only shotwell afterall)
[13:38] <luv> but apps stopping using it imemediately sounds like the behaviour the user would expect
[13:46] <bregma> fginther, does that (lp:compiz automerge move) mean someone with appropriate privs will need to manually merge approved MPs to lp:compiz now?
[13:51] <fginther> bregma, we could setup a new automerge job for lp:compiz
[13:51] <fginther> bregma, but without that someone would have to do it manually
[13:54] <fginther> bregma, I can set that up without any trouble, just let me know
[13:56] <bregma> fginther, having an automerge job would be nice for trunk compiz, but since it's not the branch being used for Ubuntu going forward, would it be using resources best focused elsewhere?
[13:57] <sil2100> I wonder how much resources does such an automerger eat up
[13:57] <bregma> I don't know, that's why I'm asking here
[13:58] <bregma> surely it takes a builder slot, and the tests get run, so it's non-trivial
[13:58] <fginther> bregma, sil2100, If we only configure it to build amd64 and i386, the resource usage is not a problem. We're only limited on armhf right now
[13:59] <luv> mardy: can you just throw at me package names I should look at ? I guess I will have a look at the code and ping you sometime next week
[13:59] <bregma> I dunno, I still see 6 hour waits when I upload to my PPAs...
[14:00] <fginther> bregma, would lp:compiz need to be dput into a ppa?
[14:00] <mardy> luv: https://launchpad.net/gnome-control-center-signon (libaccount-plugin/oauth-plugin.c) <- for the UI
[14:01] <mardy> luv: signon-plugin-oauth2 is the package which implements the OAuth2 method. IIRC it already supports clearing the token
[14:02] <fginther> bregma, and would it need an armhf build?
[14:02] <luv> so for the starters it _might_ be enough to add ui for that?
[14:02] <bregma> fginther, yes it needs a PPA since it's not landing in Ubuntu (https://launchpad.net/~compiz-team/+archive/compiz works), but lets punt on the armhf build until someone demands it
[14:03] <didrocks> who would use this ppa?
[14:03] <didrocks> bregma: you guys should rather focus on what we are delivering I guess
[14:03] <bregma> didrocks, it's for trunk compiz developers
[14:03] <didrocks> bregma: yeah, but who are compiz developers?
[14:03] <didrocks> sam is always using the source, not the package
[14:04] <bregma> I don't want my guys spending time doing manual merges to trunk compiz, so an automatic merger benefits me
[14:04] <didrocks> bregma: who would they build lp:compiz?
[14:04] <didrocks> bregma: we told we are using lp:compiz/raring
[14:05] <didrocks> it doesn't make sense for our resource to test/run something else than what we are shipping/focussing on
[14:08] <bregma> I don't think setting up an autolander for a community project that we're taking from is a very big price to pay, certainly a smaller price than contibuting to the reputation for taking and giving nothing back
[14:09] <didrocks> bregma: I'm talking about ppa build
[14:09] <didrocks> bregma: we already have too many commit ppa builds
[14:09] <didrocks> and that's taking a huge amount of our resources
[14:09] <didrocks> we committed to kill the staging ppa, I think fginther is on it for the unity one as we have dailys
[14:12] <om26er> mzanetti, can you give the output of apt-cache policy libbamf3-0 ?
[14:12] <bregma> OK, forget the PPA, if someone wants to distribute trunk binaries they can do that manually
[14:13] <mzanetti> om26er: Installed: (none)
[14:15] <om26er> mzanetti, do you have unity staging ppa ?
[14:16] <mzanetti> om26er: I don't think so... however I upgraded to raring and I still have some old quantal packages installed that make it compile...
[14:16] <mzanetti> om26er: could be that I had that one enabled some time ago
[14:16] <om26er> mzanetti, so what's wrong on raring ?
[14:16] <mzanetti> om26er: stuff not released for raring yet
[14:16] <om26er> mzanetti, if i install all the dependencies won't it work
[14:16] <om26er> aha
[14:17] <om26er> mzanetti, namely the HUD stuff ?
[14:17] <mzanetti> om26er: not sure what exactly...
[14:19] <om26er> mzanetti, it tells me if i upgrade libunity-core-6-0-dev it will remove unity because: Depends: libbamf3-0 (>= 0.4.0) but 0.3.4-0ubuntu1 is to be installed
[14:19] <mzanetti> om26er: anyways, jenkins builds on quantal with ppa:phablet-team/ppa ppa:canonical-qt5-edgers/qt5-proper and ppa:ubuntu-sdk-team/ppa
[14:19] <mzanetti> om26er: so repository-wise that should be all you need
[14:19] <mzanetti> do a apt-get build-dep qml-phone-shell once you have those (and I guess only those in regard to phablet stuff) ppas enabled
[14:21] <om26er> mzanetti, i didn't have sdk team ppa enabled,
[14:22] <mzanetti> om26er: is it working now? or does the remove-unity problem still persist?
[14:23] <om26er> mzanetti, apt-get update is running still
[14:26] <om26er> mzanetti, i installed bamf from raring, lets see how well that goes
[14:26] <mzanetti> om26er: I don't think Unity Next uses bamf any more...
[14:26] <om26er> now it doesn't remove unity but not really sure if unity will work afterwards
[14:27] <om26er> mzanetti, but it seems qml-phone-shell from phablet team ppa installs a new version of unity (nux one) so
[14:27] <om26er> mzanetti, so the shell runs on the desktop, now trying to compile
[14:29] <om26er> mzanetti, it compiles, but the shell crashes as soon as its window shows up
[14:29] <om26er> though the installed version (from the ppa) doesn't crash
[14:34] <om26er> mzanetti, now tests are running, so where should i start :)
[14:34] <mzanetti> om26er: awesome!
[14:35] <mzanetti> om26er: I'd say indicator stuff should be final enough to test it
[14:35] <mzanetti> om26er: and since greyback left the team they are orphaned too
[14:39] <om26er> mzanetti, indicators are basically not working on the desktop.. i.e. sound and battery indicators are empty, battery indicator is not working on the desktop, and as of now the date/time indicator have all the hard-coded valuues
[14:39] <om26er> but i could still tests very simple things like switching between indicators
[14:39] <mzanetti> om26er: you need to start some services...
[14:39] <mzanetti> om26er: yeah, start with that
[14:40] <mzanetti> om26er: and I will figure how to start the backend daemons for the tests
[14:40] <om26er> mzanetti, ok, great
[14:51] <mzanetti> someone: https://code.launchpad.net/~mzanetti/unity/phablet-autopilot-deps/+merge/152419
[14:51] <mzanetti> Cimi perhaps ^
[14:52] <Cimi> mzanetti, also the ones I was missing?
[14:52] <Cimi> mzanetti, qtdeclarative5-dev-tools
[14:52] <mzanetti> Cimi: huh?
[14:52] <Cimi> for unittests
[14:52] <mzanetti> Cimi: ah... thats for the build-deps
[14:52] <mzanetti> isn't it there?
[14:53] <Cimi> sorry can you check?
[14:53] <mzanetti> yep, its there
[14:53] <mzanetti> Cimi: ^
[14:54] <Cimi> mzanetti, ok
[15:06] <om26er> whats the default login password of the qml shell ?
[15:16] <Cimi> om26er, login as guest, no?
[15:16] <Cimi> om26er, I have the paswords though, somewhere :)
[15:18] <om26er> Cimi, i dont see guest option, i am running on the desktop
[15:19] <om26er> Cimi, it only shows the password box
[15:19] <Cimi> mzanetti, ^
[15:19] <cyphermox> sil2100: what's your take on the OIF tests failures this morning ?
[15:19] <mzanetti> huh... that's weird
[15:19] <mzanetti> like... really weird.
[15:20] <mzanetti> guest should always be there
[15:21] <om26er> mzanetti, due to that reason already existing tests are failing here as well... i might be something broken on my system though
[15:21] <sil2100> cyphermox: looking at oif now
[15:21] <cyphermox> thanks
[15:22] <mzanetti> om26er: there seems to be a bug indeed
[15:22] <mzanetti> om26er: let me fix it
[15:22] <om26er> ack
[15:42] <mzanetti> om26er: https://code.launchpad.net/~mzanetti/unity/phablet-fix-greeter-guest/+merge/152436
[15:48] <om26er> mzanetti, tried, works for me. approved
[15:48] <sil2100> cyphermox: seems like a singular failure, some timing issue probably - it won't happen with the next test run probably
[15:49] <cyphermox> sil2100: alright, thanks for checking
[15:49] <cyphermox> didrocks: it's as I suspected ^
[15:49] <didrocks> hum
[15:49] <cyphermox> I'm going to check what oif was trying to release, and push the buttons for it and unity?
[15:50] <didrocks> cyphermox: sounds good to me :)
[15:50] <cyphermox> k
[15:50] <didrocks> cyphermox: unity has packaging change btw
[15:50] <didrocks> as well ;)
[15:50] <cyphermox> yeah
[15:50] <sil2100> cyphermox: I might try sewing up that failing test to boost the chances of not failing a bit, but as with timing issues, it's always a roullete
[15:50] <cyphermox> hmmm vpn is really slow today
[15:51] <cyphermox> yup
[15:54]  * cyphermox publishes OIF
[15:55]  * cyphermox publishes Unity
[15:55] <cyphermox> didrocks: things should depwait, if needed?
[15:56] <didrocks> cyphermox: sorry, what do you mean?
[15:56] <cyphermox> err, unity build-depends on oif bits, right
[15:56] <didrocks> yep ;)
[15:56] <cyphermox> yeah
[15:56] <didrocks> that's why a stack is depending on the other
[15:57] <cyphermox> so if I publish both in rapid succession, if anything, there will be depwait?
[15:57] <cyphermox> hrmm, I got a launchpad timeout
[15:57] <didrocks> cyphermox: yeah, they will be blocked in proposed and won't migrate if there is a real packaging dependency
[15:57] <didrocks> oh?
[15:58] <cyphermox> and again :'(
[15:59] <cyphermox> I'll wait a bit
[15:59] <cyphermox> oif isn't published yet
[15:59] <didrocks> cyphermox: ask qa?
[16:00] <didrocks> cyphermox: they had issues yesterday, I spent part of my morning on getting things back on shape
[16:00] <didrocks> (on the DC)
[16:00] <cyphermox> *sigh*
[16:01] <fginther> bregma, FYI, I'm setting up the auto merger job, just need to test it before turning it on
[16:03] <sil2100> fginther: oh, so there will be automerging for lp:compiz?
[16:03] <fginther> sil2100, yes
[16:03] <fginther> sil2100, just nothing automatically dput to a ppa at this time
[16:08] <sil2100> Just automerging is enough I think indeed
[16:08] <bregma> fginther, thanks
[16:09] <sil2100> Thanks \o/
[16:17] <didrocks> cyphermox: any news on the timeout?
[16:18] <cyphermox> in progress
[16:19] <sil2100> didrocks: I'll approve my workaround branch - it seems to work, but there is no 100% sureness, if it does not, we can always revert it
[16:19] <sil2100> It doesn't break anything at least
[16:19] <didrocks> sil2100: ok
[16:19] <sil2100> It's just a test mod
[16:19] <didrocks> sounds good to me :)
[16:19] <sil2100> andyrock already reviewed it ;)
[16:21] <andyrock> sil2100, what branch?
[16:21] <andyrock> workaround branch?
[16:42] <sil2100> andyrock: yes
[18:07] <Trevinho> didrocks: about the new nautilus / sw updater icons... are we also going to set the .desktop file parameter to define the proper background?
[18:08] <didrocks> Trevinho: I think it's a question for seb128 ^
[18:08] <seb128> Trevinho, didrocks: yeah, question for me
[18:08] <seb128> Trevinho, those infos don't belong in the .desktop
[18:08] <Trevinho> didrocks: ah, sorry... I remember you were talking about it with JohnLea
[18:08] <seb128> Trevinho, the icon is not the same in e.g the Ubuntu and GNOME themes
[18:08] <seb128> so the color should be different depending of the theme
[18:09] <seb128> -> the info should be stored in the icon theme
[18:09] <Trevinho> seb128: ah...
[18:09] <seb128> you should invent a key file in /usr/share/icons/<theme>
[18:09] <seb128> with icon=color
[18:09] <seb128> imhp
[18:09] <seb128> imho
[18:09] <Trevinho> seb128: that's true.. however at this point we can stil check the theme in unity and use the .desktop parameter if set (considering that it's what we alredy have)
[18:10] <seb128> Trevinho, we added it to software-center and nautilus, will add it to update-manager
[18:10] <Trevinho> seb128: it's not a good solution, but it's something that's doable in not that much time
[18:10] <seb128> but that's just wrong
[18:10] <Trevinho> seb128: yeah...
[18:10] <seb128> Trevinho, it means if we change the icon (as we did for nautilus this week); we need to coordinate .desktop updates in the app as well
[18:10] <Trevinho> seb128: it should have been designed better before
[18:10] <seb128> Trevinho, I'm also not going to patch thousand of .desktop for that :p
[18:11] <seb128> it seems random to do it for 3 launcher icons
[18:11] <Trevinho> seb128: no, of course... but it's just about three or four for now
[18:11] <seb128> Trevinho, well, nautilus (as from today) and software-center has the key, update-manager will also get it in the next upload
[18:11] <seb128> Trevinho, I'm fine doing the hack for now
[18:11] <seb128> but it's not a proper solution and doesn't scale
[18:12] <seb128> so we should think at doing it in a better way ;-)
[18:12] <Trevinho> seb128: totally
[18:12] <Trevinho> seb128: ah, and for that nautilus patches? SHould I fill a FFe for them?
[18:13] <seb128> Trevinho, yes please
[18:13] <seb128> sorry about that
[18:13] <seb128> those release plan changes created issues for everyone
[18:13] <Trevinho> no problem... I probably had not the time to backport them before...
[18:13] <Trevinho> seb128: and should I work on 3.6, right?
[18:13] <seb128> yes
[18:13] <Trevinho> seb128: i,e the one already in raring..
[18:13] <Trevinho> ok fine
[18:14] <seb128> I doubt we will update to 3.8
[18:14] <seb128> we don't have gtk 3.7 in raring yet
[18:14] <seb128> and 3.8 has UI changes and some new features, and break some our patches
[18:14] <seb128> and we are feature frozen
[18:14] <seb128> so better to base on 3.6
[18:14] <Trevinho> seb128: yeah... but for what it worth, trunk works well even without it (after disabling few lines of code)