[00:44] <qengho> Zaoshanghao, good morning, everyone.
[04:40] <hikiko> Hi
[04:44] <qengho> hikiko: hi ki ko
[05:40] <hikiko> hi qengho
[05:50] <pitti> Good mornning
[06:00] <hikiko> good morning pitti
[07:32] <Trevinho> Morning
[08:01] <willcooke> hey Trevinho
[08:19] <andyrock> morning all
[08:24] <seb128> hey andyrock, how are you?
[08:24] <andyrock> hey seb128 trying to finish the branch of the copy dialog by the end of the day :D
[08:24] <andyrock> you?
[08:26] <seb128> I'm good thanks
[08:39] <hikiko> Trevinho, since I accidentally fixed compiz's show desktop too I did an MP here: https://code.launchpad.net/~hikiko/compiz/compiz.shodesktop-skip-anim-option/+merge/299276 maybe people who use compiz on mate or other DEs want to skip the fade in showdesktop :)
[08:48] <willcooke> seb128, I'm trying to rebuild u-c-c, but I don't want to make a whole .deb package, just a binary so I can test a patch.
[08:49] <willcooke> when I run autogen and then make it's looking in /usr/local/share/foo for the ui instead of /usr/share/foo
[08:49] <seb128> right
[08:49] <willcooke> I had a look at the rules file, but I can't work out how to tweak that at build time
[08:49] <seb128> --prefix=/usr
[08:49] <willcooke> hm, I tried that and it didnt work
[08:49] <seb128> ?
[08:49] <willcooke> seb128, do that with ./configure --prefix=/usr right?
[08:50] <seb128> correct
[08:50] <willcooke> I'll try again
[08:52] <Trevinho> seb128: hey
[08:52] <Trevinho> seb128: can you publish this too https://requests.ci-train.ubuntu.com/#/ticket/1614 ?
[08:53]  * Trevinho fixes the bugs in the mean time
[08:53] <Trevinho> hikiko: ok thanks.
[08:54] <seb128> Trevinho, you ignored my comment about the upstart job and g-s-d, let's see if the SRU team blocks the SRU due to it
[08:54] <Trevinho> seb128: I didn't ignore...
[08:55] <seb128> well I said that it needs to go or to be documented in the changelog
[08:55] <Trevinho> seb128: I really hope not... They're generally good people :-P
[08:55] <seb128> it's still there and still undocumented
[08:55] <seb128> well, if they do their work they should
[08:55] <seb128> their job is to catch undocumented changes
[08:55] <seb128> because those have no business being in a SRU
[08:55] <seb128> they are more often than not errors
[08:56] <seb128> they can't mind read that you wanted to remove that alternative and why
[08:56] <seb128> and you didn't asset the potential impact
[08:56] <seb128> anyway pressing the button, let's see
[08:56] <willcooke> seb128, grr - make clean
[08:56] <willcooke> :)
[08:56] <seb128> willcooke, ;-)
[08:57] <seb128> willcooke, working now?
[08:57] <willcooke> better
[08:57] <willcooke> but
[08:57] <willcooke> Failed to look up menu_file for "/usr/etc/xdg/menus/unitycc.menu"
[08:57] <seb128> lol
[08:57] <Trevinho> seb128: triggering a rebuild because of that .... Mh, ok
[08:57] <Trevinho> seb128: I'll add itt
[08:57] <seb128> Trevinho, I published
[08:58] <seb128> so too late for this round
[08:58] <Trevinho> seb128: ah ok.
[08:58] <seb128> sorry, you didn't seem open to do the change
[08:58] <seb128> let's see what SRU team says
[08:58] <seb128> willcooke, --sysconfdir=/etc
[08:58] <seb128> willcooke, unsure why you don't simply build the package which use all the right flags/options
[08:58] <seb128> easier than building 10 times and poking for what to do manually
[08:59] <willcooke> but then I have to do the install / remove dance
[08:59] <seb128> ?
[08:59] <willcooke> I have to install the .deb right?
[08:59] <willcooke> oh
[08:59] <seb128> why would you?
[08:59] <willcooke> maybe I dont
[08:59] <willcooke> because the binaries will still be there right?
[08:59] <seb128> to build the deb it does a source build
[08:59] <seb128> yes
[09:00] <seb128> also you can ctrl-C before the end of the build
[09:00] <seb128> just let it do the configure for you
[09:00] <seb128> then ctrl-C and do make
[09:00] <seb128> at least you get all the flags set up for you
[09:00] <willcooke> ah, interesting
[09:00] <willcooke> oki, I'll read up on that.  It's been a long while.  I remember something about fakeroot and that's abou tit
[09:00] <willcooke> about it
[09:02] <seb128> sudo apt-get install debscripts
[09:02] <seb128> sudo apt-get build-dep unity-control-center
[09:02] <seb128> sorry
[09:02] <seb128> sudo apt-get install devscripts
[09:02] <seb128> was a typo
[09:03] <seb128> if you use the vcs you can install bzr-buildpackage and bzr bd
[09:03] <seb128> if you get the source just use "debuild"
[09:03] <seb128> in the srcdir
[09:03] <willcooke> woo! thanks seb128
[09:04] <seb128> yw
[09:04] <seb128> works now?
[09:04] <willcooke> building
[09:04] <willcooke> if this doesnt work though, I give up :)
[09:04] <willcooke> I tried just commenting out the xml, but that didnt work
[09:05] <willcooke> needs a change in corresponding panel code too
[09:05] <willcooke> which I think is just a couple of lines commented out
[09:06] <willcooke> line 1010 in cc-power-panel.c
[09:06] <willcooke> and 1011
[09:11] <willcooke> booo
[09:11] <willcooke> but at least it built ok :)
[09:13] <seb128> willcooke, it doesn't load the panel .so from the local build
[09:13] <willcooke> ahhhhh
[09:13] <seb128> you need to copy panel/power/.libs/libpower.so over the system one
[09:14] <seb128> dpkg -S libpower.so
[09:14] <willcooke> hidden directories, of course :)
[09:16] <flexiondotorg> willcooke, I've rounded up all the duplicates for LP: #1585863
[09:17] <flexiondotorg> And have seen this LP: #1589557
[09:17] <flexiondotorg> It that SRU intended as the actual solution?
[09:22] <popey> willcooke: maybe worth keeping an eye on https://bugzilla.gnome.org/show_bug.cgi?id=764841 - GNOME Maps uses a tile provider which is changing T&C, so we may get an update from them which changes to a different tile set
[09:22] <popey> because AIUI (I think) GNOME Maps will break on Monday.
[09:26] <willcooke> flexiondotorg, I think that wifi/resume issue was fixed in upstream 1.2.2, so SRUing the new version is the intended fix.  But happyaron should comment further
[09:26] <willcooke> popey, thanks.  We get gnome-maps from Debian, so we might need to resync
[09:26] <flexiondotorg> willcooke, Thanks.
[09:27] <willcooke> flexiondotorg, did I understand the question correctly?
[09:27] <flexiondotorg> Yep :-)
[09:27] <willcooke> \o/
[09:27] <flexiondotorg> There is so much mis-information flying around about the Network Manager issues in "the community".
[09:28] <flexiondotorg> I'm just trying to get a handle on the main issues and the road to solutions.
[09:28] <flexiondotorg> Basically, trying to quite down the peanut gallery.
[09:28] <willcooke> thank you flexiondotorg
[09:28] <flexiondotorg> s/quite/quiet/
[10:05] <willcooke> seb128, sucess - of sorts
[10:05] <willcooke> now meeting, then try again
[10:05] <willcooke> and make it a bit tidier
[10:15] <seb128> willcooke, working but not really as you wanted??
[10:17] <willcooke> seb128, working, but I might have found an easier way
[10:17] <seb128> k, good
[10:18] <seb128> popey, gnome-maps is a direct sync from debian and in universe/not something we maintain, any reason it should be a concern for us?
[10:19] <popey> Only that AIUI it will break on monday. So expect bug reports in launchpad if they haven't already been reported
[10:19] <seb128> k
[10:19] <seb128> well, we are not subscribed to that component
[10:20] <seb128> so I guess it can go to the launchpad spam box :p
[10:20] <seb128> but thanks for pointing it out
[10:20] <seb128> also it's likely that Debian fixes it and than we get a direct sync
[10:20] <popey> wouldn't that need an SRU?
[10:20] <seb128> if that has users who care on stable series I guess
[10:21] <seb128> unsure how used that app is
[10:21] <seb128> I never tried it nor saw it mentioned on this channel before today
[11:26] <Trevinho> seb128: I don't see anything changed on that silo, is publication pending or what?
[11:26] <Trevinho> seb128: ah.
[11:26] <Trevinho>  Publish failed: bamf has merges in bad states.
[11:26] <Trevinho> libunity has merges in bad states.
[11:26] <Trevinho> unity has merges in bad states.
[11:26] <Trevinho> unity-lens-applications has merges in bad states
[11:27] <seb128> I pressed the button
[11:27] <seb128> didn't check the logs
[11:27] <seb128> so it failed? what is bad state?
[11:27] <Trevinho> seb128: yeah, not approved :)
[11:28] <Trevinho> seb128: andyrock is on them, once he ACK'ed I ping you again
[11:28] <seb128> k
[11:29] <seb128> you can maybe fix the upstart job, or at least the commit msg ;-)
[11:31] <andyrock> seb128 Trevinho done
[11:32] <seb128> thanks
[11:33] <pitti> does anyone know how we start a Mir session exactly? I. e. the parts between lightdm and running the session leader?
[11:33] <pitti> I suppose we don't have any Xsession.d equivalent there
[11:34] <Trevinho> pitti: mh, you want the clean way then?
[11:34] <pitti> is that just calling the equivalent of /usr/share/xsessions/my_DE.desktop?
[11:34] <pitti> which then starts the session leader, and as  soon as that stops teh session is gone?
[11:34] <pitti> Trevinho: just interested in how it works today, and how it's meant to work (they might not necessarily be the same, yes: :) )
[11:34] <Trevinho> pitti: AFAIK using unity-system-compositor you need to pass to it the FDs of lightdm for securty purposes
[11:35] <Trevinho> So you launch that trhough lightdm, but I'm not that aware of the internals
[11:35] <seb128> pitti, you would need robert_ancell for somebody who masters the details
[11:35] <Trevinho> Saviq knows that better for sure ^
[11:35] <seb128> or maybe mterry
[11:35] <pitti> so apparently if gdm wants to start a wayland session, the only thing it does is to run the corresponding .desktop from /usr/share/wayland-sessions/
[11:35] <Trevinho> yeah, these too
[11:36] <pitti> Trevinho: not interested in the details, just how a "session" is defined from the POV of the DM
[11:36] <pitti> for X it's currently "run the Exec= from the session .desktop through Xsession.d/" (or very similar)
[11:37] <Trevinho> pitti: looking at unity8-desktop-session should help you
[11:37] <Trevinho> we've /usr/share/lightdm/sessions/unity8.desktop
[11:37] <Trevinho> with X-LightDM-Session-Type=mir and Exec=lightdm-unity8-session
[11:38] <pitti> ah, so lightdm-unity8-session is the "session leader" shell script
[11:38] <Trevinho> where lightdm-unity8-session is just a script that calls lightdm-session with some qt/mir related enviromnet var sets
[11:38] <Trevinho> yes
[11:38] <Saviq> pitti, yeah and lightdm has dedicated code paths for mir to make sure it sets up unity-system-compositor
[11:38] <pitti> so lightdm doesn't really need to know about Mir, the only interface is the unity8.desktop, and no Xsession.d/
[11:39] <pitti> I'm glad the Xsession.d/ shell script madness is gone :)
[11:39] <pitti> thanks Saviq and Trevinho!
[11:39] <Trevinho> yeah, I think upstart/systemd usage is the future for that
[11:39] <pitti> that's what I'm currently discussing with upstream, yes
[11:40] <pitti> cleaning up my initial prototype
[11:40] <pitti> and I was wondering what to replace the Xsession.d wrapper with
[11:40] <pitti> I think we mostly just want to put that into the .desktop Exec= instead
[11:40] <Trevinho> I guess just having a trigger for events, then it's up to scripts..
[11:40] <Trevinho> yeah
[12:07] <willcooke> Laney, seb128 - any chance of a review and merge of this this week? https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1594816
[12:08] <seb128> willcooke, let's see if Laney replies, I can have a look tomorrow otherwise
[12:08] <seb128> it's simple enough that I can probably approve it if needed
[12:08] <willcooke> thanks seb128.  I guess this is tricky because it won't go in to 16.10 because of Gtk versions
[12:08] <seb128> but by css foo is weak, Laney probably has a much better understanding of the theme by now
[12:08] <seb128> well, Gtk isn't update
[12:08] <seb128> so we can land it now
[12:08] <willcooke> ah
[12:08] <seb128> even if it gets changed later
[12:08] <seb128> *updated
[12:09] <willcooke> seb128, also I did only need to change the power.ui file to get rid of the "when power is critically low" issue:  https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1599264
[12:10] <seb128> willcooke, do you want that in the .1?
[12:10] <willcooke> seb128, hmmmmmmm
[12:10] <seb128> willcooke, Trevinho is having a u-c-c update with the compiz lowgfx changeset
[12:10] <seb128> so we need to merge them/respin
[12:10] <willcooke> Yeah, I think so, but it's a UI change - so might need special exceptions?
[12:11] <seb128> if you want it included
[12:11] <willcooke> seb128, I'd be +1, what do you think?
[12:11] <seb128> yeah, good point
[12:11] <seb128> well if the settings is not working should be fine for a SRU
[12:11] <seb128> but we should talk to the documentation team
[12:11] <willcooke> I'll ask for a UI freeze exception anyway
[12:11] <seb128> is that setting documented there?
[12:12] <seb128> k
[12:14] <willcooke> asked in #ubuntu-doc
[12:16] <seb128> k, let me know if you get a reply
[12:16] <willcooke> seb128, would you mind testing that real quick?
[12:17] <seb128> the .ui change?
[12:17] <willcooke> yeah, just apply the patch and see if it's gone
[12:17] <seb128> can do
[12:17] <seb128> did you see the upstream commit I pointed yesterday evening when we discussed it?
[12:17] <seb128> they removed a bit of backend code which isn't needed without the ui as well
[12:18] <seb128> we might want to do the same
[12:18] <willcooke> ah, no, I missed that
[12:18] <willcooke> lemme see
[12:18] <seb128> I think I pointed one?
[12:18]  * seb128 looks at log
[12:19] <seb128> oh, I pointed to the bugzilla bug
[12:19] <seb128> same
[12:19] <willcooke> yeah
[12:20] <willcooke> so I could remove the same bits and add another patch, is that OK?
[12:21] <willcooke> or should we sync from u/s
[12:28] <willcooke> hrm, this one is waaay different to anything we have: https://bugzilla.gnome.org/attachment.cgi?id=303524&action=diff
[12:30] <willcooke> hrm, seb128 I'm out of my depth patching cc-power-panel.c
[12:32] <ricotz> hey desktopers
[12:32] <ricotz> willcooke, hi, do you mind a pm?
[12:34] <seb128> willcooke, I guess it's just a matter of removing the callback for the UI bit ... where is your .ui change?
[12:39] <willcooke> ricotz, sure
[12:42] <willcooke> seb128, https://launchpadlibrarian.net/271261080/powerui.patch
[12:42] <willcooke> is that what you meant?
[12:42] <willcooke> I think I've found the bit in cc-power-panel.c
[12:46] <seb128> willcooke, the .ui change looks fine ... k, let me know if you need help with the .c
[12:48] <willcooke> seb128, looks like we're a little way behind with out fork, but I think I got it now
[12:48] <seb128> yeah, we are way behind
[12:48] <seb128> which was sort of why we forked, they redesign the UI and we didn't want the new look
[12:48] <willcooke> doesnt matter too much though I think, as long as it works, it's not something we need to keep on the cutting edge with
[12:49] <willcooke> ahh
[12:49] <willcooke> I see
[13:10] <desrt> good morning people
[13:10] <seb128> hey desrt, wb!
[13:11] <seb128> how are you?
[13:11] <seb128> how was Canada day?
[13:12] <desrt> i'm not sure
[13:12] <desrt> probably pretty good, though :)
[13:12] <seb128> that was not monday?
[13:12]  * seb128 is unsure
[13:12] <desrt> no.  friday was the holiday
[13:13] <desrt> which, indeed, is odd
[13:13] <desrt> normally they make it on monday, but i guess because it was natively on friday, which already made it a 3-day weekend, they just left it there
[13:13] <seb128> ah ok
[13:14] <desrt> that entire long weekend was the pride parades, anyway
[13:14] <desrt> which i mostly stayed home for
[13:14]  * desrt hasn't been feeling 100% lately
[13:14] <seb128> k
[13:15] <seb128> oh :-/ hope you are going to feel better soon!
[13:15] <desrt> i should be.  i think the problem has been identified :)
[13:15] <seb128> good :-)
[14:34] <willcooke> seb128, I'm down a rabbit hole now with u-c-c :( - I think I do need to build and install a .deb because I'm trying to copy libs around to test and getting it very wrong
[14:35] <willcooke> once I do a debuild - what's the next step to get a .deb I can install?
[14:35] <seb128> what lib? how wrong?
[14:35] <seb128> debuild procudes a deb
[14:40] <didrocks> (if the build succeed :p)
[14:40] <willcooke> seb128, @ libs - I think I need to copy new ones in to the right place after I made changes to the power panel C code
[14:41] <willcooke> seb128, and wrong - like I might have deleted the proper ones and replaced them with garbage
[14:41] <willcooke> :)
[14:41] <seb128> lol
[14:41] <seb128> willcooke, well, the panel is libpower.so
[14:42] <willcooke> I was getting warnings from libunity-control-center.so.1.0.0
[14:42] <willcooke> so I tried to copy that over as well
[14:42] <seb128> and now?
[14:42] <seb128> you get an error?
[14:42] <willcooke> well, I'm getting some warnings which I think are related to the changes
[14:42] <willcooke> it's not building a deb because:
[14:43] <willcooke> oh, it's trying to sign it as you
[14:45] <seb128> that's not an error
[14:45] <seb128> it should still produce the deb
[14:45] <seb128> in the maindir, like outside the srcdir
[14:45] <seb128> or in build-area/
[14:45] <willcooke> ohhhhhhhh
[14:45] <willcooke> thanks
[14:45] <seb128> yw
[14:58] <willcooke> wooo
[14:59] <willcooke> warnings gone
[14:59] <seb128> woot
[15:06] <flocculant> willcooke: or are they ...
[15:06] <flocculant> just thought I would throw that in there :p
[15:06] <willcooke> gee, thanks pal
[15:53] <Sweet5hark1> ricotz: thanks for your enthusiasm on updating https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-yakkety-5.2&id=97262150e06b39605a4a63b6921a4010371da6ad
[15:53] <Sweet5hark1> ricotz: a few things though:
[15:53] <Sweet5hark1> ricotz: a/ please dont push changes I wrote onto the branch. All changes I push to lp are already locally commited in git, so when you recreate those changes with a newly created commit, that just creates conflicts. Also, if I have pushed something to lp, but not to the git repo, there is a good chance that there either is a problem with the change or it wasnt tested yet. As such please assume it to be _intentionally_ not pushed yet --
[15:53] <Sweet5hark1> ricotz: b/ Also, if you push changes written by others, please use --author to properly mark them for git blame etc. If you do changes inspired by someone, but which are not verbatim their work, it might be better to just name/thank the author in the commit message.
[15:53] <Sweet5hark1> ricotz: I also noted you asked upstream about rc2. Thats good in general as upstream should stick to its schedule unless there are good reasons. However, please refrain from creating tarballs from upstream tags for Ubuntu unless I am very late with that (read: like half a week). If you create the tarballs, that is not helping, because it actually creates _more_ work for me to diff/check/verify those against some I independantly created
[15:57] <Sweet5hark1> ricotz: if you want to help with the upstream tarballs, as cloph said upstream: the best way is to get into reviewing the outstanding patches that still block the tag. Alternatively, if you want to help with the Ubuntu tarballs, recreating them and verifying that there is no diff to when I upload isnt corrupted (and thus has no diff beyond e.g. fetch.log) would help too.
[16:01] <Sweet5hark1> ricotz: but -- as said in the opening, your work is much welcome, but keep in mind that packaging LibreOffice is and should be a rather slow business: Its like navigating an oil tanker. --- If you prefer something moving faster, upstream _development_ (not releng) might be something for you, and I most happily would give you an intro on how to get started ;)
[16:04] <willcooke> seb128, pour vous?  https://code.launchpad.net/~willcooke/ubuntu-themes/gtkswitchoverflow/+merge/298028
[16:05] <ricotz> Sweet5hark1, hi, thanks for the flaming and not answering to my previous messages -- I noted your complaints, but slow as in weeks-later is not helping, and you not pushing your changes is not unusual, just rebase the branch as you wish
[16:06] <seb128> sorry can't read you, hate that bug
[16:06] <ricotz> Sweet5hark1, I simply asked for an eta for the new tag nothing more
[16:06] <seb128> http://people.canonical.com/~seb128/bug.png
[16:07] <seb128> I can see notifications with text though :p
[16:07] <seb128> need to reboot but I was testing something in a snap env and didn't want to close it
[16:11] <seb128> back
[16:11] <seb128> willcooke, +1
[16:15] <Sweet5hark1> ricotz: yes, In general I need to change my unhelpful custom of pushing only rarely now that I am not alone there. But that is not what is happened here: https://launchpad.net/~bjoern-michaelsen/+archive/ubuntu/libreoffice-staging/+sourcepub/6496156/+listing-archive-extra ftbfs, so I didnt commit/push before investigating that. So umm, taking changes from someone elses private ppa that apparently broke and pushing it to the branch with
[16:17] <ricotz> Sweet5hark1, the way I did it you can easily see what I changed and you can simply rebase to your local branch by skipping the squashed commit
[16:20] <seb128> going for some exercice, bbiab
[16:25] <jbicha> popey: Ubuntu GNOME 15.10 and 16.04 ships gnome-maps
[16:26] <popey> jbicha: i thought they might
[17:38] <ricotz> Sweet5hark1, why didn't you rebase it?
[17:40] <ricotz> Sweet5hark1, also a transitional package for libreoffice-gtk might be wise to ease updating
[17:43] <Sweet5hark1> ricotz: rebase your changes on top of mine? because that would then create a different branch and thus require a forced push, "changing history"/diverted history. One should _never_ force push to a public branch.
[17:45] <ricotz> Sweet5hark1, as you said there are like 2 people working on it, so just do it
[17:45] <ricotz> Sweet5hark1, rebasing public branch is done all the time or over the places
[17:46] <Sweet5hark1> ricotz: rebasing published branches might be done. however, its never done in sane places.
[17:47] <ricotz> Sweet5hark1, dont call this branch a sane place ;P
[17:48] <Sweet5hark1> ricotz: for the next time, a workable solution, if you urgently want to have something to be included in the packaging branches is that you push to a different named branch (e.g. "feature/$something"). It can then be easily cherry-picked/merged/whatever in the ubuntu-yakkety-5.2 branch. (thats a bit like a "github pull request" -- just without the nice web-UI).
[17:49] <ricotz> Sweet5hark1, I am aware of what git is capable
[17:51] <ricotz> Sweet5hark1, and again there were weeks between your upload/changes and me pushing this
[17:57] <Sweet5hark1> ricotz: yes, I wanted to squeeze in a rc1 release on friday. but the CVE nonsense pointlessly ate too much time.
[18:08] <ricotz> Sweet5hark1, https://paste.debian.net/plain/777801
[18:13] <Sweet5hark1> ricotz: thx, willdo tomorrow.
[18:33] <willcooke> night all
[21:20] <tjaalton> anyone know if unity7 has some autoscaling applied with intel driver? because there's no scaling with the modesetting driver
[22:58] <Trevinho> tjaalton: there's no autoscaling by default
[22:58] <Trevinho> tjaalton: there's a branch that does that which we'll likely merge soon, though
[23:10] <tjaalton> Trevinho: ok, somehow it does scale with intel.. even on xenial
[23:11] <Trevinho> tjaalton: gdk might apply that automatically, but..... it shouldn't
[23:12] <tjaalton> alright