[05:41] <pitti> Good morning
[07:16] <mlankhorst> morning!
[07:17] <didrocks> good morning
[07:19] <larsu> morning!
[07:20] <ochosi> morning folks
[07:20] <didrocks> hey larsu, ochosi
[07:20] <ochosi> larsu: quick question, where is your gtk3.14 staging PPA? (so i can start to prep the xubuntu vivid themes)
[07:22] <larsu> ochosi: in the desktop team ppa
[07:22] <didrocks> pitti: hey, welcome back! I hope you had a safe flight back :)
[07:22] <didrocks> pitti: I saw that you were cooking this week-end
[07:22] <didrocks> and pushing new systemd :)
[07:23] <didrocks> pitti: I wanted to know if there was any reason you didn't include bug #1400682 patch?
[07:23] <ochosi> larsu: oh indeed. note to self: don't start asking around *before* having had coffee...
[07:24] <larsu> ochosi: haha, no worries ;)
[07:55] <pitti> bonjour didrocks, ça va !
[07:55] <pitti> didrocks: yes, flight was uneventful, and I could sleep a bit too
[07:55] <pitti> didrocks: the main reason was, I did the merge/update mostly on the plane, and I didn't have that patch downloaded  yet :/
[07:55] <pitti> didrocks: but there is a test regresssion and a timedatectl crash on i386 anyway, so I'll need to upload a new version today anyway
[07:55] <pitti> didrocks: I have that bug open now :)
[07:59] <didrocks> pitti: perfect, thanks!
[07:59] <didrocks> pitti: nice that you could sleep, how long was it btw?
[07:59] <didrocks> I guess something like 9-10 hours?
[08:00] <pitti> didrocks: 11 hours
[08:00] <pitti> 18:55 to 5:30 on the way back, 22:55 to 10:50 on the way there (1 h time zone difference)
[08:01] <didrocks> yeah, quite long, at least, no jetlag :)
[08:11] <ochosi> larsu: quick question, is file-roller on your list of apps to remove CSD?
[08:14] <mlankhorst> I should not be allowed to have smartphones :P
[08:16] <didrocks> mlankhorst: breaking one?
[08:16] <mlankhorst> yeah I cracked the screen on the aquaris
[08:17] <didrocks> it's still a build machine at least
[08:18] <mlankhorst> true but I was using it to test.. if I can figure out how to get the screen permanently unlocked and bright it would be fine
[08:19] <didrocks> mlankhorst: you can maybe get it repaired?
[08:19] <didrocks> like I don't think it's a particular screen compared to android versions
[08:20] <larsu> ochosi: I thought seb already patched that?!
[08:21] <larsu> ochosi: it doesn't have csd on latest vivid, or are you talking about a new version?
[08:21] <mlankhorst> didrocks: is it possible to unlock the screen without using the touchscreen? I already have the phone setup
[08:21] <mlankhorst> adb shell etc works
[08:21] <ochosi> larsu: this is vivid with the ubuntu-desktop PPA (gtk3.14) and file-roller: http://i.imgur.com/n36Mjdz.png
[08:22] <didrocks> mlankhorst: not that I know of
[08:22] <ochosi> larsu: i'll switch mirrors, maybe mine is lagging behind...
[08:22] <didrocks> mlankhorst: I would really try to go to a repair shop, the model from what I know is similar to the android one
[08:22] <didrocks> so they should have that screen
[08:23] <larsu> ochosi: which desktop? I have a normal title bar on unity
[08:23] <ochosi> larsu: xubuntu
[08:23] <mlankhorst> didrocks: it's identical, but yeah I guess I can take a look
[08:23] <ochosi> larsu: did you only add a check for unity?
[08:24] <ochosi> larsu: my guess is that both mythbuntu and ubuntu-studio (maybe even u-mate) would appreciate "!=gnome" instead of "==unity"
[08:24] <ochosi> and lubuntu probably
[08:24] <larsu> ochosi: it checks for GNOME: http://bazaar.launchpad.net/~ubuntu-desktop/file-roller/ubuntu/view/head:/debian/patches/bz_unity_headerbar.patch
[08:25] <ochosi> weird
[08:25] <didrocks> larsu: we really need a framework to tweak that on runtime, by capability I guess
[08:25] <didrocks> like "support-overlay-scrollbar"
[08:25] <didrocks> "support-appmenu"
[08:25] <didrocks> "disable-foo"
[08:25] <ochosi> larsu: not sure you noticed, but it has a normal menu plus a headerbar, so something is fishy there
[08:26] <didrocks> (yeah, I know, I introduced this per-session name based in 2009/2010, but I regret now :p)
[08:26] <ochosi> larsu: better visible here: http://i.imgur.com/waneudI.png
[08:27] <larsu> didrocks: ya... we talked about having another xsetting, like we do for global menu and buttons in dialog headers
[08:27] <didrocks> larsu: yeah, that would make sense
[08:27] <larsu> didrocks: consensus so far has been "oh no, not another xsetting"
[08:27] <didrocks> as there is no phone, tablet or whatsoever
[08:27] <didrocks> done properly, there is "touch screen", "keyboard", "screen size", "battery"
[08:27] <larsu> ochosi: probably because gtk-shell-shows-menubar is 0
[08:27] <didrocks> and changing the app/framework behavior on that
[08:28] <didrocks> larsu: did you try to compare that to media queries?
[08:28] <larsu> didrocks: compare what?
[08:28] <larsu> interesting idea, though...
[08:28] <didrocks> like, media queries are really trying to do that and base on capability rather than form factor/session
[08:28] <larsu> right
[08:28] <didrocks> larsu: just taking web media queries as an example as part of that discussion
[08:28] <didrocks> as an argument :)
[08:29] <didrocks> larsu: not the most important thing right now, but this discussion just makes me thinking that :)
[08:30] <larsu> didrocks: makes a lot of sense to me. We'd still need something like xsettings to provide the values, though
[08:30] <didrocks> larsu: yeah, that's clearly one of the way to achieve this
[08:30] <didrocks> just talking about the general concept, before we introduce an unity8-desktop for instance :)
[08:31] <didrocks> finding a grub script typo -> *not* fun
[08:31] <larsu> the unity8 guys have a plan
[08:31] <larsu> I don't know what that is, though
[08:31] <didrocks> we should follow the same one for desktop for sure (not implementation-wise, but for coherence)
[08:32] <didrocks> anyway, sorry for side-tracking :)
[08:32] <didrocks> waiting for grub2 to pass tests (again :p)
[08:33] <ochosi> larsu: right, so should i report a bug about this?
[08:34] <larsu> didrocks: haha, no worries :)
[08:34] <larsu> ochosi: I'm not sure what the issue is?
[08:35] <larsu> you don't have a global menu in xubuntu, do you?
[08:35] <larsu> so having that xsetting set to 0 is correct, and you get a local menu
[08:35] <ochosi> larsu: ehm, the issue is that file-roller has CSD..?
[08:35] <ochosi> the menu part is fine
[08:36] <ochosi> it was just confusing for me that there could be a mix
[08:36] <larsu> I don't understand how that is confusing. If you tell gtk that you want a header bar and a menu inside the window, that's what you get
[08:36] <larsu> what's in your XDG_CURRENT_DESKTOP?
[08:40] <ochosi> larsu: it's XFCE
[08:43] <ochosi> sry, g2g, bbl
[08:43] <larsu> ochosi: ah, it is a bug in the patch
[08:43] <larsu> I can reproduce
[08:46] <larsu> ochosi: which version do you have installed? The patch I linked to is not yet in vivid
[08:46] <larsu> http://bazaar.launchpad.net/~ubuntu-desktop/file-roller/ubuntu/revision/150
[08:46] <larsu> Laney: is file-roller file-roller blocked on anything?
[08:58] <willcooke> morning
[09:01] <didrocks> hey willcooke, feeling better?
[09:02] <Laney> heya
[09:02] <didrocks> morning Laney, good week-end?
[09:03] <larsu> morning Laney, willcooke
[09:04] <willcooke> didrocks, not really.  Paracetamol  helps
[09:04] <didrocks> urgh :/
[09:05] <didrocks> willcooke: take it easy, soon holidays!
[09:05] <willcooke> heh #
[09:05] <Laney> hey didrocks et larsu
[09:05] <willcooke> looking forward to it
[09:05] <Laney> not bad thanks, did some xmas shopping ;-)
[09:06] <Laney> you guys?
[09:06] <Laney> larsu: file-roller> not sure offhand, did robert-ancell do that one maybe?
[09:06] <didrocks> played some nice board games and finished watching breaking bad :)
[09:06] <larsu> Laney: don't know, thought you might
[09:06] <Laney> still haven't played that game I got in DC :(
[09:07] <Laney> larsu: I'll take a look
[09:08] <larsu> thanks
[09:09] <larsu> the one we have now checks for Unity to disable csd
[09:09] <larsu> the new one checks for !GNOME
[09:09] <Laney> they did that upstream?
[09:09] <larsu> no, robert_ancell did (and you committed it apparently)
[09:10] <larsu> http://bazaar.launchpad.net/~ubuntu-desktop/file-roller/ubuntu/revision/150
[09:10] <Laney> i see
[09:11] <Laney> "(blocked on gtk 3.14)"
[09:11] <darkxst> Laney, about everything is blocked on gtk 3.14 now (for us anyway!)
[09:12] <didrocks> pitti: I hope I'm using git-dpm well and patching the grub patch to generate other installed init system FYI
[09:20] <Laney> darkxst: ya, lots for us too, might be that we can deal with the remaining issues post upload
[09:20] <Laney> I need to test ubiquity though
[09:31] <ricotz> Laney, hi :), just a small request, could you define the mir minimum-requirement in the gtk+3.0 packaging?
[09:32] <Laney> what is it?
[09:37] <pitti> didrocks: sure -- if it looks ok and dpkg-source is happy, it's good :)
[09:38] <ricotz> Laney, idk, at least the trusty version is not sufficient
[09:38] <Laney> I could make it >= what-we-have-now
[09:38] <Laney> you probably just want to disable that for the PPA
[09:40] <ricotz> i know and i will, still would be nice to keep track on such things
[09:42] <ricotz> also there is a 3.14.6 ;)
[09:44] <Laney> yep
[09:57] <Laney> larsu: I see you got an ok for your icon patch ;-)
[09:58] <larsu> Laney: I dumbed it down considerably with only 2 lines left
[09:58] <Laney> ya
[09:59] <Laney> seems this is acceptable
[09:59] <larsu> speaking of which - virtmanager has large buttons because one of the toolbar icons is 48x48
[09:59]  * larsu figured that out after inspecting css for 20 minutes
[09:59] <Laney> what about the borders?
[10:01] <larsu> borders have always been on those, no?
[10:01] <larsu> I can remove them if you prefer
[10:02] <Laney> don't think so
[10:02] <Laney> one sec, lemme boot utopic
[10:06] <Laney> larsu: http://people.canonical.com/~laney/weird-things/virt-manager.png trusty
[10:07] <Laney> http://people.canonical.com/~laney/weird-things/virt-manager-new.png that's with 3.14.5
[10:08] <larsu> I stand corrected. Thanks.
[10:10] <desrt> Laney: you never told me how great schroot is
[10:10] <Laney> desrt: dude, welcome to the enlightened
[10:11] <desrt> i jhbuild on fedora on my ubuntu linode
[10:11] <desrt> yo dawg and all that
[10:11] <larsu> schroot?
[10:11] <larsu> desrt: good ... err ... morning?
[10:11] <desrt> hi :)
[10:11] <larsu> you're up early
[10:12] <desrt> larsu: it's a system for maintaining images of other distros that you can chroot into
[10:12] <desrt> it has some extremely lovely features
[10:12] <larsu> coool
[10:12] <desrt> like the way i'm using it now, it unpacks a fresh .tar each time
[10:12] <desrt> so i can explode it however i want
[10:12] <desrt> and when i logout, it deletes it
[10:12] <desrt> it also has a lot of really great features like automatically bindmounting /sys /proc /dev and (insanely usefully) /home
[10:13] <darkxst> larsu, jhbuild is a major hack, schroot would be better, but it helps finding ubuntu issues
[10:13] <desrt> i've used it from time to time when Laney wants me to fix a bug on some weird arch or another but i only really "learned" it this weekend
[10:13] <desrt> i should done that years ago
[10:13] <desrt> *shoulda
[10:13] <didrocks> desrt: you can even mount the overlay as tmpfs to avoid the unpacking :)
[10:13] <desrt> didrocks: linode has no aufs support in their kernels :(
[10:14] <didrocks> argh, so switch to btrfs and use nspawn coming with systemd 219 ;)
[10:14] <desrt> meh
[10:14] <desrt> containers are too heavy
[10:14] <desrt> i also really really really like how desrt on the outside is desrt on the inside
[10:14] <desrt> it's totally perfect
[10:14] <larsu> darkxst: this seems to be for a different use case than jhbuild...
[10:14] <didrocks> desrt: ahah, nicely said :)
[10:14] <larsu> (which I'm actualy quite fond of these days)
[10:15]  * desrt did a pile of jhbuild hacking over the weekend
[10:15] <darkxst> larsu, yes GNOME upstream has no sbuild/schroot stugg
[10:15] <desrt> i added support for finding out about _all_ of the things that are needed to build the lower bits of gnome
[10:15] <desrt> including the stuff that we couldn't previously add checks for (libxml2-python, docbook-xsl)
[10:16] <desrt> and now i have a new mode that dumps the full list in machine readable form like pkgconfig:egl,c_include:jpeglib.h,...
[10:16] <darkxst> desrt, like making system modules satisfy jhbuild?
[10:17] <desrt> and another script that runs that list against a Contents.gz from apt-file and comes up with various solutions
[10:17] <desrt> darkxst: ya...
[10:17] <willcooke> desrt, you're up early
[10:17] <Laney> or late ...
[10:17] <desrt> early :)
[10:17] <desrt> Laney: maybe you could help me with some of the issues i hit
[10:17] <desrt> i asked in #debian but it was pretty slow over the weekend
[10:18] <Laney> #debian-devel might be better for that kind of q
[10:18] <desrt> first issue is that i want to find a way to effectively say: apt install a b 'c | d' e f 'g | h'
[10:18] <desrt> where c/d are alternatives for the same functionality and g/h the same for another
[10:18] <desrt> like jpeg vs. jpeg-turbo or something
[10:19] <desrt> currently my script takes all of the possibile combinations of the alternatives, does apt dry-runs on them all and calculates a 'cost' based on the number of reported Inst and Remv lines (with removals costing 1000 times more than adds)
[10:20] <desrt> then it picks the lowest cost
[10:20] <Laney> I'd build a .deb with that in Depends: and let apt figure it out
[10:20] <desrt> unfortunately that involves doing apt dry-runs of ~1000 operations over 192 possible combinations... which takes 5-10 minutes :(
[10:20] <desrt> Laney: ya.... i was hoping for a better way
[10:20] <desrt> more direct
[10:21] <Laney> that's what sbuild does when it resolves build-deps, for example
[10:21] <desrt> also: Depends: lines are a bit "opinionated", right?
[10:21] <Laney> or there's a script called mk-build-deps
[10:21] <desrt> like, the thing on the left is the one that is taken unless the others are already installed, no?
[10:21] <Laney> ya
[10:21] <Laney> well, kind of, if it's not installable then it'll try the other one
[10:21] <desrt> does it do that even if the 'cost' is high?
[10:22] <desrt> like for example say i had libfooa and libfoob mutually conflicting
[10:22] <desrt> they have corresponding libfooa-dev and libfoob-c
[10:22] <desrt> *-dev, sorry
[10:22] <desrt> then package 'c' depends on libfooa-dev | libfoob-dev
[10:22] <desrt> and my system had libfoob installed
[10:22] <desrt> will apt uninstall libfoob in order to get me libfooa-dev just because i didn't have libfoob-dev?
[10:24] <desrt> because in that case i'd sort of hope for the more reasonable "oh... he's already got libfoob... so probably he just wants the -dev of that"... which is what my 'minimum cost' thing was tilting for
[10:25] <desrt> you know.. mk-build-deps is not bad...... and it would additionally give me an artifact that i could install in order to force all of the depends of my jhbuild to stay installed
[10:26] <Laney> I think apt is smart enough to prefer not to remove packages if it can
[10:26] <Laney> but you get into mvo territory at this point
[10:26] <desrt> i already sent him an email :)
[10:27] <Laney> or you could do some experimentation
[10:27] <desrt> i'll see if i can play with mk-build-deps
[10:27] <desrt> ya...
[10:27] <desrt> see what it gets me
[10:27] <Laney> 'equivs' is a tool for building packages which don't do anything other than have metadata
[10:27] <Laney> so you can test using that
[10:27] <desrt> great advice.  thanks.
[10:27] <Laney> or even use it to generate your fake package for dep solving
[10:27] <desrt> i had another issue, but it's less likely you know about it (or even that it has a solution at all)
[10:28] <desrt> i want a command that i can call that will answer the question "which package do i have to install in order to get a given uri into the system xml catalog"
[10:29] <desrt> ie: i want to know what will make 'xmlcatalog /etc/xml/catalog http://docbook.sourceforge.net/release/xsl/current/' return a positive result
[10:31] <desrt> (my current thinking towards a best solution here is to hardcode the package name 'docbook-xsl'... i don't plan on the xml depends of jhbuild undergoing a dramatic expansion any time soon... but a generic solution would be nice...)
[10:39] <Laney> sorry, had a guy around checking the energy efficiency of the house... gone now...
[10:40] <desrt> very nice of him
[10:40] <Laney> I think that particular operation is done by packages invoking update-xmlcatalog in their mantainer scripts which are usually generated by dh_installxmlcatalog during the build
[10:40] <Laney> soooo no I don't know of a way you could determine that :)
[10:40] <desrt> ya.. i'm aware of that much, but it's sort of the opposite of what i want
[10:40] <desrt> i'd need somewhere a database of all the people who ever do that
[10:41] <desrt> in general, we need to start getting better information about this sort of stuff into apt...
[10:41]  * desrt wants to apt install pkgconfig:gl or apt install c_include:jpeglib.h or apt install python2:libxml2
[10:42] <desrt> or (xml:http://whatever)
[10:45] <desrt> Laney: is there a better way to install-with-deps than using apt-get install -f?
[10:46] <desrt> the proposed solution in my contrived case above is removing the package with the alternative depends
[10:46] <Laney> maybe gdebi, but I'm not sure what resolver it uses
[10:46] <Laney> or make a local repository using dpkg-scanpackages and put that into sources.list
[10:47] <Laney> ISTR some talk about apt getting "apt install .deb"
[10:48] <desrt> Laney: long overdue, that one....
[10:49] <Laney> DonKult @ #debian-devel might know more - he's an apt guy
[10:51] <desrt> Laney: the idea of adding a local repository is interesting -- i don't even actually need the .deb files in that case
[10:51] <desrt> can just ask apt "what would you do" based on the Packages file
[10:51] <desrt> in any case, the result of the experiment is that apt does 'the wrong thing'
[10:55] <desrt> (ie: it wants to remove libfoob)
[11:06] <Laney> ubiquity seems ok with new gtk
[11:11] <Laney> closing in on the upload
[11:29] <xnox> \o/ Laney
[11:31] <Laney> xnox: remembered to check it this time ;-)
[11:31] <Laney> ps. nice christmas tree
[11:31] <xnox> =))))
[11:33] <Laney> shared mine with you on g+
[11:37] <xnox> Laney: haven't been on g+ for a while.
[11:37] <xnox> .... lennart invited me to systemd hack-fest.
[11:37] <Laney> haha
[11:37] <Laney> it seemed like a reasonable option from the android share menu
[11:37] <xnox> pitti: are you going for lennarts/systemd fosdem hackfest?
[11:38] <pitti> xnox: yes, I will
[11:39] <xnox> didrocks: as well and marco d'Itri.
[11:41] <xnox> pitti: i'll ponder about it.
[11:59] <Laney> larsu: do you need to get someone to review https://code.launchpad.net/~larsu/ubuntu-themes/gtk-314 ?
[12:09] <larsu> Laney: yes, but I've just started working on it again
[12:09] <larsu> seb128 tried it last week and didn't notice any issues
[12:09] <Laney> yes I've been trying it too
[12:09] <Laney> not hugely qualified to review though
[12:10] <larsu> that's fine, I'm not hugely qualified to write it ;)
[12:10] <Laney> if we're going to upload gtk then this needs to go in too
[12:10] <larsu> yep
[12:11]  * larsu is fixing toolbar buttons right now
[12:11] <Laney> ok, please put up a MP when that's done :)
[12:12] <larsu> "done". lol.
[12:12] <Laney> I believe in you!
[12:12] <larsu> haha - there are little issues all over the place
[12:12] <larsu> and changing something in the theme _always_ breaks something else
[12:13] <larsu> we need some way to properly test theming
[12:13] <Laney> it doesn't have to be 100% to get it in vivid
[12:13] <larsu> of course
[12:13] <larsu> let me finish the toolbar/flat button stuff and then I'll MR
[12:14] <Laney> did you notice that the session selector in unity-greeter got a border too?
[12:14] <Laney> :)
[12:15] <larsu> I did now :)
[12:15] <Laney> put it on the pad
[12:15] <Laney> not a priority
[12:15] <larsu> yep
[12:15] <larsu> thanks
[12:22] <pitti> didrocks: FYI, I sent a fix for the timedatectl regression upstream and fixed test_profile in Debian git; I'm now trying to reproduce the NSpawn.test_boot failure (doesn't happen locally)
[12:23] <pitti> didrocks: so uploading a new version will still take a bit, but I'll see to getting it done by tomorrow
[12:23] <pitti> I'll be off for the afternoon
[12:25] <desrt> pitti: take care
[12:25] <pitti> hey desrt, how are yoU?
[12:25] <desrt> busy :)
[12:25] <didrocks> pitti: thanks for keeping me posted, now that I sent the grub thing, I'm about to finish some desktop developer stuff. Then, moving on on more systemd work
[12:25] <didrocks> pitti: still want to discuss with you about fsck before pushing more :)
[12:25] <didrocks> but let's do that tomorrow
[12:26] <desrt> pitti: you going to the systemd hackfest in brussels?
[12:30] <pitti> desrt: (OTP) yes, I will
[12:30] <pitti> desrt: will you be on fosdem, too?
[12:30] <desrt> yes
[12:31] <desrt> hopefully will get some kdbus stuff nicely tied up there
[12:41] <willcooke> didrocks, cheapo ebay laptop battery update.... wont charge above 60% now.
[12:42] <didrocks> willcooke: yeah, so the cheap was really "cheap" :/
[12:43] <willcooke> quelle surprise
[12:43] <didrocks> well, see the positive side: it didn't explode when you plugged it
[12:43] <willcooke> :D
[12:43] <didrocks> ;)
[12:43] <larsu> yet
[12:43] <willcooke> LOL!
[12:44] <didrocks> roh
[12:51] <pitti> didrocks: I responded to bug 1400682
[12:53] <xnox> Laney: i don't see any pictures shared with me on G+... did you use the right account instead of a defunct @canonical.com one?
[12:53] <Laney> don't know, I typed your name in the app ^o)
[12:55] <didrocks> pitti: agreed, doing this change and closing the bug report then
[12:55] <Laney> xnox: https://plus.google.com/u/0/109160032876474505377/posts that one
[12:56] <xnox> Laney: right - so I see if it I go to your page, but I didn't get a notification about it =/
[12:57] <xnox> Laney: yours is lovely and tall and nice toys - just enough.
[12:57] <xnox> Laney: mine is much shorter than that and more fluffy
[12:57] <Laney> it expanded after we got it home
[12:57] <Laney> wanted something skinnier
[12:57] <Laney> i like the fluffiness ^_^
[13:02] <didrocks> pitti: I guess on the bug report, you wanted to tell "graphical.target.d" or really "display-manager.service.d" (and so, using RequiredBy=)
[13:21] <ochosi> larsu: ah right. the version of file-roller i have is 3.12.2-0ubuntu1 (so standard vivid)
[13:32] <ricotz> Laney, was it intended to drop "--include-image-data" from update-icon-cache?
[13:32] <didrocks> pitti: done, tested and uploaded in https://launchpad.net/ubuntu/+source/xdiagnose/3.7.1
[13:33]  * didrocks goes for some cycling
[13:37] <pitti> didrocks: I actually meant display-manager.service.d/, so that we can keep to Wants=
[13:37] <pitti> didrocks: oh wow, thanks!
[13:38] <didrocks> pitti: the issue is that we would have graphical.target still active
[13:38] <didrocks> I'm unsure we would want that
[13:38] <pitti> didrocks: you didn't ref/close the bug?
[13:38] <didrocks> right now, it's overriding well as a Requires
[13:38] <pitti> oh, invalid
[13:38] <didrocks> pitti: yeah, it's not exactly the same approach/component, so didn't retarget it
[13:39] <pitti> didrocks: anyway, great to see that this .d/ thing works!
[13:39] <didrocks> yeah ;)
[13:39] <pitti> didrocks: now, 218 isn't in vivid yet, but I'll work on that as fast as possible :)
[13:39] <didrocks> pitti: we can just override display-manager.service.d if you prefer in the future, I'm just not feeling confortable letting graphical.target as active when the graphical server didn't really start
[13:39] <didrocks> pitti: actually, it's working on 217 as well
[13:40] <didrocks> 218 just introduce the edit command
[13:40] <pitti> didrocks: ok, that seems fine
[13:40] <pitti> didrocks: oh right
[13:40] <didrocks> this override mechanism are how generators are working in /run/system/ actually :)
[13:40] <didrocks> I just didn't map into my brain, but yeah, way nicer
[13:40] <didrocks> thanks for the suggestion :)
[13:42]  * pitti hgus didrocks
[13:42] <pitti> ok, I'm off for some hours to do some christmas shopping
[13:43]  * didrocks hugs pitti back
[13:43] <didrocks> enjoy! (and good luck)
[13:44]  * didrocks really off to some exercise now
[14:11] <ochosi> larsu: another question, if i may, is patching CSD in gnome-calculator also on your list?
[14:13] <dgadomski> hello everyone
[14:14] <dgadomski> Trevinho: hey, do you remember the focus storing change (fix for bug #1125442)?
[14:16] <dgadomski> Trevinho: there was a regression caused by the change (bug #1393020), do you have any idea how to differentiate viewport moving caused "manually" from those caused by clicking on the launcher (like in the bug description) on the compiz level?
[14:16] <Trevinho> dgadomski: hi
[14:17] <Trevinho> dgadomski: mh, no I don't remember a way now... but I could investigate
[14:18] <Trevinho> dgadomski: however, Brandon Schaefer (now offline, it will be back in about 2hrs) said me he prepared a fix for that changwe
[14:18] <Trevinho> dgadomski: so, if you wait him to join yo could have a chat with him about that
[14:19] <larsu> ochosi: again, works on unity :)
[14:19] <larsu> ochosi: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/gnome-calculator/vivid/view/head:/debian/patches/git_no_headerbars_in_unity.patch
[14:19] <larsu> ochosi: probably we should update this to !GNOME as well
[14:19] <ochosi> yeah: if (!is_desktop ("Unity"))
[14:19] <dgadomski> Trevinho: great, I will talk to him, thanks!
[14:20] <ochosi> larsu: yeah, would be great in order for things to be consistent, at least across desktops
[14:20] <Laney> ricotz: that's only in the gtk2 one, right? and I think it's going to be dropped from there too
[14:20] <Laney> so... yes
[14:54] <draven33> need some help with compiz in 14.04  i activatewd dual loghin compoz and metacity an can't align the 3d windows on the cube they form outside the cube
[15:14] <ricotz> Laney, i meant the gtk3 3.14.5 packaging
[15:14] <Laney> where do you think it got dropped?
[15:16] <ricotz> Laney, iirc I added it in the early gtk3 packaging for gnome3 ppa, and I thought it is needed still
[15:18] <ricotz> ignore me if it isn't needed anymore and i will drop it as well
[15:50] <Mirv> I wonder if any core-dev would be happy to ack compiz https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/46/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff ? ...or if I'll ask for better changelog. all of that is related to the line "added support for multi-arch installations"
[15:51] <Mirv> mostly the cleanup to remove all debian/tmp/ from *.install could have been mentioned as well
[16:54] <bschaefer> dgadomski, hello!
[16:55] <dgadomski> bschaefer: hey
[16:55] <bschaefer> did you have some questions about the workspace needing reverting?
[16:56] <dgadomski> I wanted to fix bug #1125442, but Trevinho told me that you were working on some fixes already
[16:56] <bschaefer> dgadomski, well i wasn't actually work on a fix atm
[16:57] <bschaefer> i fixed a bug your prev merge caused but that was a simple fix. The main other issue would be to not re-focus a cached window when clicking on a launcher icon
[16:58] <bschaefer> Trevinho, do you remember how the launcher icon actually focus an icon on a differnet workspace?
[16:58] <bschaefer> we call a workspace switch in unity or compiz?
[16:58] <dgadomski> bschaefer, oh, sorry, I pasted wrong link, this was the bug I was thinking about: bug #1393020
[16:59] <bschaefer> dgadomski, right, i assigned my self that bug just because i reverted your merge
[16:59] <bschaefer> (not really a fix though)
[16:59] <Trevinho> bschaefer: all unity side should bein PluginAdapter::FocusWindowGroup
[16:59]  * bschaefer looks
[17:00] <Trevinho> bschaefer: so, there's no direct request to switch to another vp... it just happens when you ask compiz to focus a window
[17:00] <bschaefer> Trevinho, i see, so we can patch that bit of code in compiz i suppose?
[17:00] <bschaefer> that should be in ... screen/window.cpp?
[17:00] <Trevinho> bschaefer: I suppose
[17:01] <Trevinho> bschaefer: probably on activate window
[17:01] <bschaefer> Trevinho, well ideally we need to think of a better way to cache said window
[17:06] <bschaefer> dgadomski, but ideally, we need to come up with a way to restore focus on that cached window
[17:06] <bschaefer> if and only if its on that workspace and we are not focusing a new window on that workspace
[17:07] <dgadomski> bschaefer: I was debugging this and I saw that moveViewport (where the window is cached) is called in both cases and I was not able to determine how to differentiate between "manual" viewport changing versus the launcher-initiated
[17:08] <bschaefer> right, that was a worry of mine as well... though we might have to figure out a better way to cache the window
[17:08] <bschaefer> dgadomski, theres a place somewhere in compiz
[17:08] <bschaefer> that focuses a window
[17:08] <bschaefer> thats what the launcher uses, and in there it switches the viewport
[17:09] <bschaefer> so we can detect when the launcher is being used, or rather we can detect when a window is being focus (hopefully?)
[17:09]  * bschaefer looks at compiz
[17:21] <bschaefer> Trevinho, dgadomski looks like the wall plugin causes the window to be moved
[17:21] <bschaefer> you can test that out by disabling the plugin then attempting to click on a launcher icon... strange
[17:23] <dgadomski> bschaefer: what do you mean by "causes the window to be moved"?
[17:25] <bschaefer> dgadomski, err not window to be moved but workspace/viewport to be moved
[17:26] <dgadomski> bschaefer: yeah, and if you change the wall to e.g. cube you are still affected by this issue, so this needs to be fixed below the plugin layer
[17:26] <bschaefer> dgadomski, right, but we need to ensure the plugins work as well
[17:27] <bschaefer> dgadomski, the issue being that the unity launcher is using the wall plugin (or rather the wall plugin is auto moving workspaces to the "wanted" focused window)
[17:27]  * bschaefer might not be making much sense
[17:28] <dgadomski> bschaefer: I see your point, the unity launcher also works in the same way with cube, so probably cube also moves viewports while focusing a window outside current viewport
[17:29] <bschaefer> dgadomski, right, so if those plugins are disabled
[17:29] <bschaefer> all is well
[17:29] <bschaefer> but we have the wall enabled, meaning it'll attempt to focus a window
[17:29] <bschaefer> on its viewport
[17:29] <bschaefer> so we need to add a case in that plugin to be handled
[17:29] <bschaefer> dgadomski, then i think we can get the fix re-merged :)
[17:29] <bschaefer> compiz is ... like a N headed monster where N is the number of plugins enabled...
[17:31] <dgadomski> bschaefer: Trevinho mentioned earlier that there may be a way to recognize the reason behind the moveViewport inside compiz
[17:31] <larsu> bschaefer: lol, more like N = 2^n_plugins
[17:31] <bschaefer> larsu, haha... true
[17:31] <willcooke> +RAND(10)
[17:31] <bschaefer> Trevinho, ^
[17:32] <bschaefer> n^n
[17:32] <Trevinho> dgadomski: ehm? :P
[17:33] <bschaefer> i like to imagine the best way this could turn out... We need to have ideally on each workspace a last focused window
[17:33] <dgadomski> "<Trevinho> dgadomski: mh, no I don't remember a way now... but I could investigate"
[17:33] <bschaefer> when we have landed on said workspace we need a way to check "Did we just change focus to get here?" vs "We just got here, change focus to last focused window"
[17:34] <bschaefer> those two cases are the tricky part, but what "should" happen
[17:34] <dgadomski> Trevinho: so if you don't remember a way not it means that there probably was a *WAY* :)
[17:34] <bschaefer> is as soon as the launcher focuses the window, the last focused window for that workspace should be updated
[17:34] <bschaefer> which would resolve our issues
[17:34] <Trevinho> dgadomski: oh, yeah... there is... :)
[17:34] <bschaefer> Trevinho, haha
[17:35] <bschaefer> dgadomski, so we need to look at making sure we update the last focused cached window per workspace
[17:35] <bschaefer> if we can do that, then when the launcher focuses a window on any workspace, that workspace updates its last focused window and we are set :)
[17:35] <Trevinho> bschaefer: it's very likely that each workspace plugin (like wall or cube) implements that switch
[17:35] <bschaefer> Trevinho, i greped
[17:35] <bschaefer> Trevinho, but it doesn't matter, we can get around this under the hood
[17:36] <bschaefer> Trevinho, all we have to check for is FOCUS OF NEW WINDOW
[17:36] <bschaefer> when a new window is focused update the last focused window on the workspace its on
[17:36] <Trevinho> bschaefer: I see..
[17:36] <bschaefer> so when we move to that workspace it will always get focus
[17:36] <bschaefer> that sound reasonable?
[17:36] <bschaefer> as...other wise im just imagining a mess of code to handle all strange edge cases
[17:39] <Trevinho> bschaefer: yes, that seems correct
[17:39] <bschaefer> so instead of updating the last focused window each time we move workspace
[17:40] <bschaefer> the details could be hammered out
[17:42] <dgadomski> bschaefer: are you thinking about caching focused window e.g. in CompWindow::activate?
[17:42] <bschaefer> dgadomski, not 100% sure where but that might be a good place
[17:43] <bschaefer> dgadomski, we just need a way to cache a window per workspace
[17:43] <bschaefer> and when a new window is focused to update that cache array
[18:05]  * didrocks waves good evening and good night
[18:40] <dgadomski> bschaefer: caching in CompWindow::activate does not work as expected, I will continue debugging tomorrow morning
[18:41] <bschaefer> dgadomski, sounds good, i think the screen will have to know about it
[18:41] <bschaefer> vs the window
[18:41] <bschaefer> good luck!
[18:42] <dgadomski> bschaefer: thanks! take care
[18:44] <bschaefer> you to!