[02:23] <mterry> robert_ancell, you around?
[02:24] <robert_ancell> mterry, yep
[02:24] <mterry> robert_ancell, how does lightdm / logind interaction go?  I see lightdm calling Unlock, but not Activate.  Does logind track VTs or something for that?
[02:24] <robert_ancell> mterry, I think so
[02:24] <mterry> robert_ancell, because I'm thinking in Mir land (at least), it needs to call Activate
[02:25] <robert_ancell> ok
[02:25] <mterry> robert_ancell, and for safety's sake should probably just always call Activate after Unlock
[02:25] <mterry> robert_ancell, because that's the semantics it wants
[02:26] <mterry> robert_ancell, I tested and this dumb patch fixed session tracking with my split greeter branches: http://paste.ubuntu.com/7105848/
[02:27] <mterry> though maybe it shouldn't try to Activate if Unlock failed
[02:27] <robert_ancell> Shame we can't do a "UnlockAndActivate"
[02:27] <robert_ancell> yeah
[02:27] <mterry> for atomic usage?  Yeah
[02:28] <mterry> robert_ancell, do you want a quick branch?
[02:28] <robert_ancell> mterry, sure. Is this needed for 14.04?
[02:28] <mterry> robert_ancell, ideally?
[02:29] <robert_ancell> mterry, ok
[02:33] <mterry> robert_ancell, https://code.launchpad.net/~mterry/lightdm/activate-after-unlocking/+merge/211235
[02:37] <mterry> robert_ancell, I'm going to sleep soon.  So if there are trivial changes needed, please feel free to make them yourself.  Else we can catch up on it tomorrow
[02:37] <robert_ancell> mterry, bye
[02:38] <mterry> robert_ancell, bye!
[04:35] <mterry> robert_ancell, actually, maybe that code should be part of session_set_active
[04:35] <mterry> semantically.
[04:36] <robert_ancell> mterry, ah, yes
[04:36] <robert_ancell> I should have reviewed that closer
[04:36] <mterry> robert_ancell, sorry.  Just had a falling-to-sleep realization
[04:36] <robert_ancell> I think in all normal cases unlock = activate but we should fix that before something changes that
[04:37] <mterry> robert_ancell, I'm not sure what we do in the autologin-in-background case.  Not sure if we ever call Unlock or not, but we do call session_set_active, and we should be clear with logind which session is active in that case
[04:37] <robert_ancell> yes
[04:37] <robert_ancell> brb, just testing 1.9.12
[04:38] <mterry> robert_ancell, I can whip up something tomorrow
[04:38] <mterry> oh whoops
[04:40] <robert_ancell> mterry, ok, heading off now. I'll merge your branch in the morning :)
[04:40] <mterry> robert_ancell, OK  :)  sorry for back and forth
[04:40] <robert_ancell> no worries
[05:38] <pitti> desrt: hey
[05:38] <pitti> Good morning
[05:39] <pitti> desrt: we haven't maintained jhbuild on jenkins for a while; it didn't get that much attention, and my impression was that gnome-continuous superseded it?
[05:44] <darkxst> pitti, I didnt even know there was jhbuild on  jenkins, however I think it still has its place for development work
[05:45] <darkxst> and it often breaks on ubuntu for various reasons
[05:51] <darkxst> pitti, or just read that as I still use jhbuild, since I havent got around to working out how OSTree works for local git builds!
[06:14] <darkxst> pitti, can you upload https://code.launchpad.net/~albertsmuktupavels/gnome-menus/fix-menus-in-gnome-flashback-session-real/+merge/211246 (I reviewed it, but don't actually have upload rights for gnome-menus yet)
[06:16] <darkxst> err, on second thoughts seemes the new file is not installed
[06:28] <darkxst> pitti, ^ fixed, can you upload?
[06:45] <pitti> darkxst: ack, will do
[06:54] <darkxst> pitti, thanks
[07:14]  * hyperair wonders if anyone besides me sees issues with the unity lockscreen
[08:53] <jibel> with latest trusty iso, when the live session starts the keyboard shortcut overlay of unity is displayed
[08:53] <jibel> is it a known issue?
[08:56] <seb128> good morning desktopers
[08:56] <seb128> jibel, that's a feature, not a bug (it's displaying the overview on first user login so you know about the keybinding)
[08:57] <seb128> I'm not sure I like the feature though, so feel free to open a bug if you don't like it either, so we have a place to discuss that on launchpad ;-)
[08:58] <jibel> seb128, ah a "feature" :) I'll file a bug, thanks!
[08:58] <seb128> jibel, yw
[08:58] <seb128> jibel, bug #1283619 for reference
[08:58] <ubot2> Launchpad bug 1283619 in Unity "No "first run" tutorial for Unity/Ubuntu" [High,Fix committed] https://launchpad.net/bugs/1283619
[09:01] <jibel> displaying the shortcut hint doesn't really address the original proposition
[09:02] <Laney> helloooooooooo!
[09:04] <seb128> Laney, hey, welcome back!
[09:05] <seb128> Laney, did you have a good week off?
[09:05] <Laney> hey seb128
[09:05] <seb128> jibel, well, apparently JohnLea approved the solution there...
[09:05] <Laney> was very good thanks: riding a tandem, going to the seaside, eating lots of nice food, drinking good beer and playing board games ;-)
[09:06] <jibel> seb128, do you know how to disable it because it interferes with automated tests of the installer?
[09:06] <Laney> how was your week/weekend?
[09:07] <seb128> jibel, create a file ~/.cache/unity/first_run.stamp
[09:07] <jibel> ta
[09:07] <seb128> jibel, that's what they did for lightdm guest sessions
[09:08] <seb128> Laney, nice ;-)
[09:09] <Laney> https://fbcdn-sphotos-b-a.akamaihd.net/hphotos-ak-prn2/t1/1187126_10101065908145328_306761324_n.jpg
[09:09] <seb128> Laney, week was good, the lock screen work finally landed, they had some rounds of bugfixing since (and still some issues), vUDS happened, bugs got fixed ... pretty standard week in Ubuntu world ;-)
[09:09] <Laney> oh yeah vUDS
[09:09] <Laney> did much happen there?
[09:09] <seb128> not that I know
[09:09] <seb128> schedule was half empty
[09:09] <seb128> not in client at least, seems core was better
[09:10] <seb128> they are good discussions on e.g the work that need to happen around systemd
[09:10] <seb128> oh
[09:10] <seb128> I almost forgot
[09:10] <ogra_> well, we also only had one room ... it had a session every hour though
[09:10] <seb128> qt5.2 landed on friday
[09:10] <ogra_> (core that is)
[09:10] <Laney> oh yeah I saw some plussing about that
[09:11] <seb128> hopefully this week is bugfixing only ;-)
[09:11] <didrocks> ahah, don't dream…
[09:12] <didrocks> there is the new scope infra transition
[09:12] <didrocks> the icon theme transition
[09:12] <didrocks> and 5.2 fixes to get a promotable image :p
[09:12] <seb128> didrocks, I was speaking about desktop ;-)
[09:12] <didrocks> yeah, on that, you should be quieter ;)
[09:12] <Laney> let me see the queue
[09:12] <seb128> though the scope one worries me :p
[09:12] <seb128> that's likely to impact desktop in some ways?
[09:12] <ogra_> heh, brits ... always after the queue
[09:13] <didrocks> seb128: normally no, they are separated binaries
[09:13] <didrocks> and only activated by the shell
[09:13] <Laney> you wait your turn, grawert
[09:13] <seb128> good
[09:13] <ogra_> lol
[09:13] <Laney> https://bugs.launchpad.net/ubuntu/?field.searchtext=&search=Search&field.status:list=NEW&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-release&field.structural_subscriber=&field.component-empty-marker=1&fie ...
[09:13] <Laney> ... ld.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&orderby=status& ...
[09:13] <Laney> ... start=0
[09:13] <didrocks> however, I would appreciate some help in case some packages are getting stuck in proposed or not building
[09:13] <Laney> erm
[09:13]  * Laney runs
[09:13] <seb128> lol
[09:13] <Laney> http://is.gd/wmIkMg
[09:13] <didrocks> as I had to butcher a little bit the archive :)
[09:14] <Laney> you had to WHAT!
[09:14]  * didrocks didn't put back his knives in the kitchen
[09:15] <Sweetshark> Moin!
[09:15] <seb128> didrocks, xnox did some fixing over the w.e, re-enable some packages to build on all archs, and got things true proposed
[09:15] <seb128> Sweetshark, hey
[09:15] <didrocks> seb128: yeah, I saw that, that's sweet :)
[09:16] <didrocks> seb128: so, with the sdk fix that's in flight, normally, we should be in a way better position
[09:16] <seb128> great
[09:16] <seb128> Laney, if you look to ffes, can I point you to https://launchpad.net/bugs/1207812 ? ;-)
[09:17] <ubot2> Launchpad bug 1207812 in libimobiledevice (Ubuntu) "[FFe] Update libimobiledevice to support iOS 7, fix Trust Prompt Looping" [Medium,New]
[09:17] <Sweetshark> seb128: current status: autopkgtest run on my machine but not in the adt VMs - so of for some fun debugging ...
[09:17] <seb128> Laney, it should be an "easy" one (like not a lot of choice, we can't really not get support for the current iOS version)
[09:17] <xnox> seb128: didrocks: from archive point of view it would be amazing if dee-qt got fixed. Cause then we'd be able to drop all arch-restrictions. The current test-failure is very puzzling https://launchpad.net/ubuntu/+source/dee-qt/3.3+14.04.20140116-0ubuntu2
[09:17] <seb128> Sweetshark, "nice" ... you can try to claim its jibel's fault and see if you can get him to debug it for you ;-)
[09:18] <Laney> seb128: yeah, will do soon
[09:18] <seb128> thanks
[09:19] <seb128> xnox, did you try asking mhr3 or tsdgeos?
[09:19] <didrocks> xnox: yeah, same failures on ppc* only, weird. The thing is that dee-qt is considered as abandonned, but I'll try to get someone on it
[09:19] <didrocks> like mhr3 :)
[09:19]  * mhr3 hides
[09:20] <didrocks> mhr3: hey hey! :)
[09:20] <didrocks> good morrrrrrning ;)
[09:20] <seb128> mhr3, good morning, happy monday!
[09:20] <xnox> didrocks: if it's abandoned, why does our stack rely on it? e.g. dee-qt -> (hud, unity8) -> unity-action-api -> ubuntu-ui-toolkit -> (everything)
[09:20] <didrocks> xnox: don't ask me, ask upstream ;)
[09:21] <mhr3> who said it's abandoned?
[09:21] <mhr3> seb128, fine morning to you sir! :)
[09:21] <didrocks> last time I asked a fix for it. I can grep the logs
[09:21] <Sweetshark> seb128: nah, its pretty sure my fault somehow. Java doesnt find one of the native LibreOffice libs for connecting to LO.
[09:21] <tsdgeos> seb128: didrocks: do you guys happen to know how i can debug this? a) kdm doesn't seem to want to star unity anymore b) lightdm doesn't want to show anything on my system
[09:21] <xnox> didrocks: also from the department of possibly abandoned things, you are listed as maintainer of "oneconf" and it has a very strange python3.4 failures =) do you know who I can poke to try to fix it?
[09:21] <seb128> tsdgeos, is "ubuntu-session" installed?
[09:21] <didrocks> xnox: barry did the python3 part, so I guess he's the most experienced with this
[09:22] <didrocks> port*
[09:22] <tsdgeos> seb128: i do
[09:22] <Sweetshark> seb128: The "fun" is that it takes some 55 minutes to provision the VM (install all the deps etc.) -- the test itself would only take some 5 minutes after that.
[09:22] <xnox> mhr3: can you glance at the test-results of the two failed builds on this page https://launchpad.net/ubuntu/+source/dee-qt/3.3+14.04.20140116-0ubuntu2 ? a few people are very puzzled by it.
[09:22] <xnox> mhr3: maybe it "all makes sense to you" =)
[09:22] <seb128> tsdgeos, it was not and you do install it? or is it already installed?
[09:22] <mhr3> xnox, i guess that was with 5.2?
[09:23] <tsdgeos> seb128: it was installed, this was working on friday
[09:23] <seb128> xnox, likely an endian issue if it's ppc only?
[09:23] <tsdgeos> stopped working over the weekend
[09:23] <didrocks> mhr3: it's with 5.2, right
[09:23] <seb128> tsdgeos, weird, what happens when you try to log in?
[09:23] <tsdgeos> seb128: kdm seems to "close itself to give way to the session"
[09:23] <tsdgeos> and it stays there
[09:24] <tsdgeos> no gnome-session or unity or anything running
[09:24] <mhr3> is it just mp or is being weird now?
[09:24] <mhr3> s/mp/me/
[09:24] <mhr3> eh
[09:24] <mhr3> is it just me or is lp being weird now?
[09:24] <seb128> tsdgeos, do you get your background image? can you e.g right click on it (said differently, is nautilus running)
[09:24] <seb128> mhr3, just you
[09:24] <xnox> mhr3: seb128: powerpc is big endian, ppc64el is little endian -> thus not an endianneess issue.
[09:24] <mhr3> getting timeouts, bzr pull not working :/
[09:24] <tsdgeos> seb128: no, i still have kdm's background image
[09:25] <xnox> mhr3: this is the first time ever where we have build-dependncies satisfiable on both of those arches, thus it never built on those before.
[09:25] <seb128> tsdgeos, can you share the ~/.xsession-errors and ~/.cache/upstart/gnome-session-ubuntu.log logs?
[09:25] <xnox> gnome-session or ubuntu-session? =)
[09:25] <mhr3> xnox, looks like an issue in qt itself to me
[09:26] <tsdgeos> seb128: http://paste.ubuntu.com/7107114/
[09:26] <xnox> mhr3: right, how'd i go around making a minimal test-case to try? e.g. did Slot not generate anything at all?!
[09:26] <tsdgeos> last line does actually seem like it could be a problem
[09:27] <seb128> xnox, "init: No s'ha pogut obtenir la instància gnome-session: Unknown parameter: XDG_CURRENT_DESKTOP"
[09:27] <mhr3> xnox, it's failing on the new-style connect()
[09:27] <mhr3> xnox, so the question only is whether it's the param for the connect that cause it, or something more fundamental
[09:28] <xnox> seb128: catalan? i thought you were german.
[09:28] <tsdgeos> xnox: that's my paste
[09:29] <xnox> seb128: tsdgeos: i'll look into it to see where the breakage is coming from.
[09:29] <xnox> tsdgeos: could you give me package version numbers you have installed? e.g. "$ dpkg -l"
[09:30] <seb128> tsdgeos, right, they changed the upstart jobs on friday
[09:30] <seb128> xnox, does that error make any sense to you?
[09:30] <xnox> seb128: yes, I understand the error message.
[09:31] <seb128> tsdgeos, likely due to https://launchpadlibrarian.net/169426095/gnome-session_3.9.90-0ubuntu11_3.9.90-0ubuntu12.diff.gz
[09:32] <tsdgeos> xnox: http://paste.ubuntu.com/7107128/
[09:32] <tsdgeos> seb128: looks like it
[09:32] <xnox> seb128: so at the time the job was started, XDG_CURRENT_DESKTOP environment variable was not set, or available at all. (e.g. not passed in cmd-line args)
[09:32] <Laney> Mirv: can qtcreator-plugin-cmake be uploaded?
[09:32] <xnox> seb128: what typically on a normal machine sets that environmental variable?
[09:33] <xnox> seb128: cause, if it's gnome-session itself, we have a bootstrapping problem =)
[09:33] <seb128> xnox, I think gnome-session itself
[09:33] <tsdgeos> seb128: so let me patch that manually back
[09:33] <Mirv> Laney: yes
[09:33] <Laney> Mirv: you or me? :-)
[09:33] <Mirv> Laney: I don't have upload rights to that particular package, as it's not in the Qt5 set. so, you.
[09:33] <seb128> xnox, later I can remind our discussion from last week on how trivial changes have potential to create issues :p
[09:33] <Laney> okay
[09:34] <seb128> Laney, did you hit conflict on CMakeProjectManager.pluginspec ? ;-)
[09:36] <mhr3> xnox, so, yea, i could change the tests in dee-qt to not use the functor-based connect() but that's just hiding the fundamental problem, qt needs to be fixed
[09:36] <seb128> Laney, if so, bug #1292615 if you want to fix it/reference from the changelog
[09:36] <ubot2> Launchpad bug 1292615 in qtcreator-plugin-cmake (Ubuntu) "package qtcreator-plugin-cmake (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/x86_64-linux-gnu/qtcreator/plugins/QtProject/libCMakeProjectManager.so', which is also in package qtcreator 2.8.1-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1292615
[09:36] <Laney> seb128: yes
[09:37] <Laney> it's already fixed in trunk
[09:37] <seb128> ok
[09:37] <Laney> Mirv: I might s/Conflicts/Breaks/ though - would that make you scream or cry?
[09:37] <Mirv> Laney: no it would not
[09:38] <Laney> too many unnecessary conflicts can cause problems when upgrading
[09:38] <Mirv> just thank you
[09:38] <Laney> great, ok, doing
[09:38] <Laney> ta
[09:40] <xnox> seb128: then it can't be using that as an instance var, as it doesn't know it ahead of time.
[09:41] <seb128> xnox, how come it's working for most users?
[09:42] <tsdgeos> seb128: that indeed makes it work for me again
[09:42] <tsdgeos> i mean "reverting that patch"
[09:43] <seb128> xnox, ok, so lightdm set it, seems like kdm doesn't
[09:44] <seb128> xnox, which is probably why it's working for most of us
[09:44] <seb128> tsdgeos, that doesn't explain why lightdm stopped working for you, can you report a bug using ubuntu-bug lightdm?
[09:45] <tsdgeos> seb128: well, maybe it never worked (or not for a long time)
[09:45] <seb128> oh, you usually use kdm and tried to switch when you hit the bug?
[09:45] <tsdgeos> seb128: yep
[09:45] <seb128> k
[09:45] <seb128> tsdgeos, so yeah, that change that was made is buggy for kdm (and probably other dms)
[09:46] <tsdgeos> seb128: you want a bug for both things? (one for lightdm and one for the other change?)
[09:46] <seb128> tsdgeos, yes please, gnome-session and lightdm
[09:46] <tsdgeos> ok
[09:46] <tsdgeos> will do
[09:46] <seb128> the lightdm one please use ubuntu-bug
[09:46] <seb128> so we have the logs
[09:46] <seb128> thanks!
[10:04] <Laney> Mirv: please to merge lp:~laney/qtcreator-plugin-cmake/release
[10:14] <Laney> man, I can understand why you'd think that keyboard shortcuts popup is a bug
[10:16] <Mirv> Laney: done, thanks, bzoltan is thankful too
[10:16] <Laney> no worries
[10:23] <didrocks> mhr3: mind workarounding the issue in dee-qt for now on?
[10:23] <didrocks> mhr3: it's going to block quite some apps
[10:24] <didrocks> or maybe tsdgeos knows what's the issue in qt 5.2 itself is
[10:24] <mhr3> didrocks, imo that's just going to uncover the same issue further down the road
[10:24] <tsdgeos> didrocks: that thing that fails in ppc?
[10:24] <didrocks> tsdgeos: yeah
[10:24] <tsdgeos> no idea other than "is ppc supported upstream"?
[10:24] <didrocks> tsdgeos: well, you are the closest to upstream, so you should know
[10:24] <didrocks> tsdgeos: but ppc64el is supported in ubuntu
[10:25] <tsdgeos> didrocks: i doubt it is, let me check
[10:25] <didrocks> tsdgeos: well, we should find a way… or we shouldn't have switched to Qt then
[10:26] <Laney> has there been a change to lose borders on windows or am I making things up?
[10:27] <didrocks> Laney: yeah, 0px width
[10:27] <Laney> didrocks: on purpose?
[10:27] <didrocks> yeah
[10:27] <didrocks> AFAIK
[10:27] <seb128> Laney, theme update
[10:27] <Laney> I see
[10:28] <tsdgeos> didrocks: closest thing is https://bugreports.qt-project.org/browse/QTBUG-35218
[10:28] <tsdgeos> which says "well maybe, but we don't build it"
[10:28] <tsdgeos> didrocks: if you give me access to a ppc machine i can try findind out what's wrong
[10:29] <seb128> Laney, https://plus.google.com/108101042776723451522/posts/KTMMrCC3mZW
[10:29] <didrocks> tsdgeos: let me give you links for our porter boxes
[10:30] <Laney> seb128: okay, cheers
[10:30] <seb128> yw
[10:30] <Laney> I think I like it after thinking "wtf it's different"
[10:31] <seb128> ;-)
[10:32] <Fudus> in the uds was it decided to use local menus or continue with global?
[10:33] <seb128> Fudus, don't change the default so far but ask design to do user testing and revisit once we get feedback from that
[10:34] <Mirv> me as new to LIM found it not necessarily obvious but no less obvious than having it outside the window at the top of the screen
[10:35] <Mirv> I liked it and stuck to it then
[10:38] <Laney> Trevinho: Do you think we could find a way to skip the first-run shortcut overlay for existing users?
[10:39] <seb128> I wonder if we should just disable that feature
[10:39] <seb128> it's goes against the "no initial wizard" decision we made by then
[10:39] <Trevinho> Laney: mh, I thought about that.. I was thinking about checking if settings have been modified, but that's not something it might work 100% of times
[10:40] <seb128> if we come back on that we should do a proper/useful wizard, just showing keybindings seems like useful for be could do better
[10:40] <Trevinho> seb128: well, that was a design decision... As "this is the best we can have, for now".
[10:41] <ogra_> hmm since the new screensaver is in my XPS13 behaves oddly ...
[10:41] <Trevinho> Laney: anyway just touching ~/.cache/unity/first_run.stamp before running unity is enough
[10:41] <ochosi> hey Trevinho
[10:41] <seb128> ogra_, "oddly"?
[10:41] <Trevinho> ochosi: hi
[10:41] <Laney> Trevinho: Yeah, you have to find out how to do that when necessary
[10:42] <ogra_> screen doesnt shut off when i close the lid ... and after unlocking it get the desktop for a few seconds and then a black screen with a clock in the upper right
[10:42] <ogra_> wiggling the pointer gets me the desktop back then
[10:42] <Laney> You could have a migration script that runs it
[10:42] <Laney> s/runs/creates/
[10:42] <Trevinho> Laney: I tought that, but aren't migration running on first time?
[10:42] <Laney> I think so - you still need a condition to test for
[10:42] <ochosi> Trevinho: i got a bugreport for the new unity decorations that i wanted to quickly ask you about. is this expected? (it obviously doesn't affect ambiance or radiance, but mixed-color themes): https://github-camo.global.ssl.fastly.net/8b0e0720c71a10a947fdcddb0ab0932aed4a2757/687474703a2f2f692e696d6775722e636f6d2f79723774544a342e706e67
[10:43] <Laney> like does compiz create some cache?
[10:44] <Trevinho> ochosi: oh... well we're using the same theme for both titles, so... I guess we need to fix it, to use style context... I just didn't think we needed it, but it seems we have to.
[10:44] <Laney> I guess you could do any such check in unity itself though
[10:44] <tsdgeos> didrocks: so we do not build ppc in the landing silos, and that's why we didn't find that problem before?
[10:45] <ochosi> Trevinho: yeah, thought so. would be nice if it would just use the same color as the panel menuitems i guess
[10:45] <hikiko> hello :)
[10:45] <didrocks> tsdgeos: in some silos, yeah, and due to the complexity of the landing, the decisions (even if we enabled only on that silo) was to dismiss it or you guys would have been blocked for way longer
[10:45] <tsdgeos> sure
[10:49] <hikiko> I just added a slider in u-c-c to set the gnome's scaling-factor and I wonder if there's a way to avoid the following problem:
[10:49] <seb128> hikiko, hey
[10:49] <hikiko> hi seb128  :)
[10:49] <hikiko> when I set the slider to a value (let's say 2)
[10:50] <seb128> Laney, you have a desktop config right, does that have an audio input device integrated? ;-)
[10:50] <hikiko> and then I manually change the scaling-factor from gsettings set ...
[10:50] <hikiko> the slider is not updated
[10:50] <hikiko> is there any mechanism
[10:50] <hikiko> maybe signals etc so that I update the slider's value
[10:51] <Laney> seb128: a what?!
[10:51] <hikiko> when the slider changes from outside u-c-c
[10:51] <hikiko> ?
[10:52] <seb128> hikiko, yes, https://developer.gnome.org/gio/2.35/GSettings.html#g-settings-bind
[10:52] <hikiko> thank you seb128
[10:52] <seb128> yw
[10:52] <Laney> You might want to do that in u-s-d though
[10:53] <Laney> to update the unity value when the gtk value changes?
[10:53]  * Laney dunno
[10:53] <seb128> Laney, no, we decided to not bind the unity and gtk settings
[10:53] <Laney> separate sliders?
[10:53] <seb128> but rather have a "desktop UI scale" and an "scale applications" slider next to it
[10:53] <seb128> yes
[10:53] <Laney> I see
[10:53] <seb128> it was not possible to bind both properly
[10:54] <seb128> like if you put 1.5 scale for unity
[10:54] <seb128> you might prefer 1 or 2 as GTK scale
[10:54] <seb128> we can't really force it on you
[10:54] <seb128> also the unity setting is by screen
[10:54] <seb128> where the GTK one is not
[10:54] <Laney> it makes it more obvious who to blame, I guess
[10:55] <Laney> if you can't get the application slider to give you a decent result then you get to blame gtk :P
[10:55] <seb128> lol, yeah
[10:56] <seb128> you are going to be screwed anyway if you use a laptop with low-dpi and an external monitor which is hidpi ... and there is no way for us to know which one you prefer
[10:56] <seb128> Laney, so, coming back to your desktop, do you have anything listing in settings->sound->input?
[10:57] <Laney> oh I see
[10:57] <seb128> Laney, I'm looking for somebody to test https://code.launchpad.net/~binli/unity-control-center/1291862/+merge/211258 ... I've only laptops and they come with an input line, so I can't test
[10:57] <Laney> I didn't know what you were asking me
[10:57] <seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1291862
[10:57] <ubot2> Launchpad bug 1291862 in gnome-control-center (Ubuntu) "[soundnua]mic volume adjust bar is gray if you open sound-nua input tab earlier than plugging micphone" [Low,Confirmed]
[10:57] <Laney> I have a microphone socket on my motherboard's soundcard
[10:58] <seb128> so you should get an empty list until you plug something in that socket?
[10:58] <Laney> I think so, sec
[10:59] <Laney> yep
[10:59] <seb128> cool
[10:59] <seb128> well, if you can test those changes that would be nice ;-)
[11:06] <Laney> doing
[11:07] <seb128> thanks
[11:07] <Laney> hmm, you reverted that user login history change?
[11:07] <Laney> did lightdm get a fix?
[11:07] <seb128> yes, it was wrong, it was listing any sudo session
[11:07] <seb128> yes
[11:08] <Laney> neat
[11:08] <seb128> lightdm correctly register sessions now
[11:10] <Sweetshark> pitti, jibel: https://gist.github.com/bjoernmichaelsen/9597485 <- huh?
[11:11] <hikiko> one more question, do you know if this: http://i.imgur.com/7Uj9x2v.png is a custom gimp widget or it has a name?
[11:12] <seb128> hikiko, I don't think that's a standard GTK widget
[11:12] <seb128> do you need to do that? but your 2 sliders are not linked
[11:12] <seb128> e.g moving one is not going to change the other one
[11:12] <jibel> Sweetshark, looking
[11:13] <hikiko> no they aren't, I just thought that it would be nice if the user could lock the sliders in 1 desktop so that he can change the ui_scale and the apps scaling-factor changes accordingly
[11:14] <hikiko> but ok, I don't think it's necessary
[11:14] <hikiko> it was just an idea
[11:15] <seb128> hikiko, yeah, you don't want to start in that direction, especially that one is by-screen and the other one is not
[11:15] <hikiko> true :)
[11:22] <jibel> Sweetshark, you need to prepare a test VM before running the tests. You can do it with ./bin/prepare-testbed amd64 . Did you do it and does it exist?
[11:22] <jibel> Sweetshark, you should have a file called /tmp/adt/disks/pristine-trusty-amd64*.img
[11:25] <Sweetshark> jibel: I did, but I rebooted. I expected this to survive reboots. Thanks! ;)
[11:26] <jibel> Sweetshark, you can set another location by adding BASEDIR=<path> in ~/.adtrc . By default it is set to BASEDIR=${TMPDIR:-/tmp}/adt
[11:27] <Sweetshark> jibel: ok, will consider it next time ...
[11:27] <jibel> Sweetshark, I'll fix the runner to actually display the error message whne the base image doesn't exists.
[11:27] <Sweetshark> jibel: that would be nice.
[11:30] <Laney> seb128: it's slightly buggy
[11:31] <seb128> Laney, can you comment on the mp? I already added some "would be nice to do that" items
[11:31] <seb128> e.g it's not ready for this landing round
[11:31] <Laney> Am doing, just testing a possible fix
[11:40] <Sweetshark> jibel: now I get "Could not access KVM kernel module: Permission denied\nfailed to initialize KVM: Permission denied\n2014-03-17 12:37:30 PM: Failure: VM failed to start in 180s. Aborting!" on the ./prepare-testbed step. ... but I just see I have packages kept back (including kernel). Doing a dist-upgrade.
[11:41] <jibel> Sweetshark, is your user member of the group kvm?
[11:42] <Sweetshark> jibel: hmm, no.
[11:42] <Sweetshark> jibel: "It worked before" :/
[11:48] <Laney> there's a bug where that breaks on upgrades
[11:48] <Laney> restart
[11:50] <Laney> I've told hallyn about it before but he might want reminding
[11:51] <Sweetshark> jibel: dist-upgrade seems to have helped
[12:07] <hikiko> seb128, could you get a look at: https://code.launchpad.net/~hikiko/unity-control-center/u-c-c.apps-slider/+merge/211301 when you have a moment?
[12:07] <seb128> hikiko, ok
[12:29] <pitti> Sweetshark: your URL doesn't exist?
[12:31] <Sweetshark> pitti: already killed, thanks to jibel for helping be out.
[12:32] <pitti> Sweetshark: ah, saw backscroll now; alles klar!
[12:33] <Sweetshark> pitti: (gist is like pastebin, but automatically put your stuff in git. and since you logged in anyway, its trivial to kill your snipplets, so no need for giving it a lifetime beforehand. I prefer that.)
[12:46] <seb128> hikiko, reviewed, commented on the mp, I think you should get input from design though (mpt might be a good person to ask about that)
[12:46] <mpt> ’Sup.
[12:46] <seb128> mpt, https://code.launchpad.net/~hikiko/unity-control-center/u-c-c.apps-slider/+merge/211301
[12:47] <mpt> What’s the easiest way to see what it looks like?
[12:47] <seb128> mpt, http://people.canonical.com/~seb128/display.png
[12:47] <mpt> Ah thanks :)
[12:47] <seb128> mpt, she is adding the "App scale" slider at the bottom
[12:48] <mpt> Why two scales?
[12:48] <seb128> mpt, note that for more fun "UI scale" is by-screen, where "App scale" is not
[12:48] <mpt> Oh dear
[12:48] <seb128> mpt, because we didn't manage to conciliate both in one slider
[12:48] <seb128> mpt, GTK handle only int-based scaling number and for all screens
[12:48] <seb128> so basically GTK scales by 1 or 2
[12:48] <seb128> Unity/qml scale with more granularity
[12:48]  * desrt yawns
[12:48] <seb128> and by screen
[12:49] <seb128> mpt, that's the best we came with during the vUDS session
[12:49] <seb128> having the "UI scale" and we suggested a toggle to scale apps that would set the GTK setting to "scale by 2"
[12:49] <seb128> desrt, good morning!
[12:50] <desrt> hi :)
[12:51] <seb128> mpt, sorry, it's one of those ridiculous situation ... in any case if you have any suggestion we would welcome them ;-) (I would go for a checkbox for the GTK setting personally because a slider which does 1-2 is not going to be useful, and I doubt anyone wants to scale to 4)
[12:52] <hikiko> haha :)
[12:52] <hikiko> seb128, there are problems with the checkbox though
[12:53]  * mpt crashes compiz while testing the “UI scale” slider
[12:53] <hikiko> ?
[12:53] <hikiko> the ui-scale is another slider, you need to install a package
[12:53] <mpt> So, this panel has some settings that apply to all displays, and some settings that apply just to the currently selected display. They should at least be grouped into sections.
[12:53] <hikiko> let me find it
[12:53] <hikiko> yes mpt
[12:54] <hikiko> maybe I should move the slider first of all
[12:54] <mpt> hikiko, how much time do you have? :)
[12:54] <hikiko> mpt I have to fix this before the release, so let's say the end of the week
[12:54] <hikiko> so that we have 1 more week
[12:55] <hikiko> for testing
[12:55] <Laney> This is a user interface breaking change too
[12:55] <mpt> yes
[12:55] <Laney> So you need to coordinate with the documentation team
[12:55] <Laney> (given that we're after User Interface Freeze now)
[12:56] <hikiko> who should i contact Laney ?
[12:56] <mpt> hikiko, ok, I’m going to print this out and work on it this afternoon, and I’ll give you a suggested layout tomorrow morning
[12:56] <hikiko> that
[12:56] <hikiko> that sounds great mpt
[12:56] <larsu> desrt: morning. Can you compile this (with `valac --pkg=gio-2.0 test.vala`) ? http://paste.debian.net/88150/
[12:56] <seb128> mpt, thanks
[12:56] <hikiko> thanks!
[12:56] <Laney> hikiko: https://wiki.ubuntu.com/UserInterfaceFreeze
[12:57] <Laney> → https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
[12:57] <seb128> mpt, btw, easier one on https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1291608 if you have an opinion (I think the icons are a nice touch and we should keep them, but robert_ancell doesn't seem to agree)
[12:57] <ubot2> Launchpad bug 1291608 in unity-control-center (Ubuntu) "No user icons provided / user icons not used" [Medium,Triaged]
[12:58] <desrt> larsu: this is an interface.  drop the 'override'
[12:58] <mpt> seb128, I commented on that already
[12:58] <seb128> mpt, oh, right, I see that
[12:58] <desrt> larsu: also: you can't subclass simpleactiongroup
[12:58] <hikiko> thank you Laney :) I will email the list
[12:58] <seb128> mpt, your suggestion was mine, so you basically recommend 1 ;-)
[12:59] <larsu> desrt: ah, thanks. Why not?
[12:59] <desrt> larsu: it's private
[12:59] <larsu> desrt: gapplication.c does it, no? I simply want a remoteactiongroup wrapper. Why is it so hard?
[12:59] <seb128> mpt, in fact we made g-c-c and u-c-c co-installable so users can have GNOME and Unity installed on the same machine, but we can't ship the same icons in both or we would have conflicts (or duplicates if we rename) ... anyway, I'm just going to split those in their own binary and make u-c-c recommends it
[12:59] <mpt> seb128, well sure, but since people are unlikely to install both at once, I don’t think you need to worry about the disk space from duplication
[12:59] <mpt> Oh, I see
[12:59] <seb128> mpt, it's not disk space ;-)
[13:00] <mpt> ok
[13:00] <seb128> ideally we would move the icons to the theme or something
[13:00] <seb128> or to the artwork package
[13:00] <desrt> larsu: composition over inheritance :)
[13:00] <larsu> desrt: still, gapplication inherits from simpleactiongroup
[13:01] <desrt> no.
[13:01] <desrt> it composes with it, in fact
[13:01] <larsu> I mean its exportactions internal thing
[13:01] <larsu> G_DEFINE_TYPE_WITH_CODE (GApplicationExportedActions, g_application_exported_actions, G_TYPE_SIMPLE_ACTION_GROUP, G_IMPLEMENT_INTERFACE (G_TYPE_REMOTE_ACTION_GROUP, g_application_exported_actions_iface_init))
[13:01] <seb128> Laney, opinion on making a new binary g-c-c-faces from g-c-c source? (or different naming? or moving those images to an artwork package instead)?
[13:01] <desrt> that's a wrong composition-style wrapper
[13:02] <desrt> >:|
[13:02] <larsu> why?
[13:02] <desrt> oh wow.
[13:02] <desrt> huh
[13:02] <larsu> and can I do the same anyway?
[13:02] <desrt> simpleactiongroup _is_ subclassable
[13:02] <desrt> disregard
[13:02] <desrt> it's gsimpleaction that's not
[13:02] <larsu> heh, I was about to say after checking the source
[13:02] <desrt> yes... you can do the same
[13:03] <larsu> cool. Thanks.
[13:03] <desrt> but i'll look down on you
[13:03] <desrt> ...for doing the same thing as i did
[13:03]  * larsu didn't know not to use 'override' for interfaces
[13:03] <larsu> desrt: I pretend to be bothered by that
[13:03] <Laney> seb128: does it just enumerate a directory?
[13:03] <seb128> Laney, yes
[13:03] <desrt> larsu: i'm bothered enough for both of us :)
[13:03] <larsu> haha
[13:03] <Laney> seb128: ok, seems fine then
[13:03] <larsu> bbiab, getting some lunch
[13:04]  * desrt justifies it with some "internal, not API, and would be nicer if we had interface delegation" and gets some coffee
[13:04] <seb128> Laney, which one? adding a -faces binary to g-c-c and making u-c-c recommends it?
[13:04] <Laney> yeah
[13:04] <seb128> thanks
[13:04] <Laney> If necessary then design could provide some to drop in instead
[13:04] <seb128> larsu, waouh, you are talking to desrt before he got his coffee now?!
[13:05] <seb128> Laney, right, but I'm not going to hold on that
[13:05] <desrt> seb128: not his fault :)
[13:05] <Laney> sure
[13:09] <hikiko> mpt, the documentation freeze is on thursday (20th)
[13:10] <hikiko> so, it would be nice if we submit the change before that
[13:11] <hikiko> (I think that if the change is not too big, 2 days are enough)
[13:17] <seb128> hikiko, don't worry about that, mpt said he would have a design recommendation by tomorrow, we can then do the change and ask for an UIFe, should be on track
[13:18] <hikiko> ok! :)
[13:30] <larsu> desrt, seb128: it's not?
[13:31] <desrt> unless we want to add an indicator to status.ubuntu.com
[13:31] <desrt> [ ] desrt has had coffee yet
[13:31] <desrt> and then make people responsible to check it
[13:31] <seb128> ;-)
[13:31] <larsu> desrt: just change your nick :)
[13:31] <Laney> Nah, we need a spreadsheet
[13:31] <Laney> desrt conversation request
[13:31] <larsu> desrt_nocoffeeyet
[13:31] <desrt> senkafo
[13:39] <seb128> interesting
[13:39] <seb128> https://mail.gnome.org/archives/distributor-list/2014-March/msg00000.html
[13:39] <seb128> "Evolution moving to an annual schedule"
[13:40] <ogra_> desrt, hey ho
[13:41] <desrt> ogra_: hi
[13:41] <ogra_> desrt, i'm just looking at http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-239.png... (thats a phone boot) and notice that there are plenty of short running dbus-daemon processes ... one seems to be started by dconf-service do you know why =
[13:41] <ogra_> ?
[13:42] <desrt> fascinating!!
[13:42] <desrt> so what you describe is impossible, but possible
[13:42] <ogra_> lol
[13:42] <desrt> as in, there is a codepath (dbus autolaunching) that does that
[13:42] <desrt> but it shouldn't happen if DBUS_SESSION_BUS_ADDRESS is set
[13:42] <desrt> which it ought to be
[13:43] <desrt> unless somehow this is not being set properly by upstart process launching...
[13:43] <ogra_> hmm
[13:43] <desrt> 'cause ya.. that's obviously kinda bogus :)
[13:44] <ogra_> http://paste.ubuntu.com/7108190/
[13:44] <ogra_> thats the dbus session upstart job we have
[13:45] <ogra_> it even exports it via initctl to make sure its there
[13:45] <desrt> maybe that's not working properly somehow?
[13:45] <ogra_> hmm
[13:45] <desrt> also: evil: >$HOME/.cache/upstart/dbus-session
[13:46] <desrt> use XDG_RUNTIME_DIR for these sorts of files
[13:46] <desrt> even better: put a symlink there called 'bus'
[13:46] <desrt> this is what systemd is doing now, iirc
[13:47] <ogra_> well, i dont think there are many things using that
[13:47] <ogra_> except for AP tests
[13:47] <desrt> there will be soon :)
[13:47] <desrt> (the 'bus' symlink i mean)
[13:47] <ogra_> with upstart sessions ?
[13:47] <desrt> we're chatting about changing the dbus spec so that client libraries will look there
[13:48] <ogra_> we wont see systemd sessions within the next two releases on the phone :)
[13:48] <desrt> ya.. just saying it would make my life easier (as a client library developer) if upstart and systemd put the socket symlink in the same place
[13:48] <ogra_> (init yes, user sessions not yet)
[13:49] <desrt> in the future we hope not to have the environment variable at all
[13:49] <ogra_> upstart doesnt do that at all ... thats a phone specific hack to give autopilot a chance to grab the session bus address when run via adb
[13:49] <desrt> ah
[13:49] <desrt> if it's a hack, that's cool i guess :)
[13:49] <ogra_> i doubt anything on desktop makes use of it
[13:50] <ogra_> (though it is available there indeed, since the hack is in a generic upstart job)
[13:50] <ogra_> anyway, i dont think thats the issue
[13:51] <ogra_> ogra@styx:~$ adb shell sudo -u phablet -i env|grep DBUS
[13:51] <ogra_> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-EPvS1kiyt2
[13:51] <ogra_> i get a proper address var in the environment
[13:52] <desrt> 'proper'
[13:52] <desrt> typically, if set by the daemon itself, this will have contained the daemon's guid
[13:52] <desrt> i wonder if that is causing problems, somehow
[13:52] <desrt> mine looks like this, for example: unix:abstract=/tmp/dbus-XqaPPHcDhr,guid=f5f2bbc7473da60765f0d9325326ef0e
[13:52] <ogra_> oh
[13:52] <desrt> also: it's very strange that you use mktemp to create an abstract socket name....
[13:53] <desrt> since mktemp operates in the filesystem namespace and abstract sockets are not
[13:53] <ogra_> hmm, true
[13:54] <desrt> (not suggesting that this is the problem -- but maybe there is a very small security issue here)
[13:54] <ogra_> ogra@styx:~$ env|grep dbus
[13:54] <ogra_> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-9QLMnQyO6e
[13:54] <ogra_> thats on my trusty laptop
[13:54] <Laney> which uses the same job
[13:54] <ogra_> so we have the same missing guid on desktop too
[13:54] <ogra_> yeah
[13:55] <ogra_> now i wonder how you got the guid into your env
[13:56] <desrt> ogra_: so https://git.gnome.org/browse/glib/tree/gio/gdbusaddress.c#n1003
[13:56] <desrt> this is likely the codepath that's causing the dbus-daemon to pop into existence
[13:58] <desrt> this code is hit in two cases
[13:58] <desrt> first is in the case taht DBUS_SESSION_BUS_ADDRESS is unset
[13:58] <desrt> second is in the case that it has the string "autolaunch:" in it
[13:59] <desrt> so i don't think that missing guid would really be a problem
[13:59] <desrt> unless that causes the address to be rejected and we get a fallback or something
[13:59] <ogra_> right, but the non abstract socket might
[14:00] <ogra_> wasnt it so that dbus automatically set that in the past ?
[14:00] <ogra_> without us having to create a file with mktemp ?
[14:00] <desrt> yes
[14:00]  * ogra_ vaguely remembers that starting dbus used to put the socket address into the env itself 
[14:00] <desrt> i'm not exactly sure why you do it the way you do it now
[14:00]  * ogra_ neither 
[14:01] <ogra_> lets see what happens if i comment it :)
[14:01] <desrt> well
[14:01] <desrt> you need to get the session bus address one way or the other
[14:01] <desrt> so that you can push it into the global environment
[14:02] <desrt> fwiw, i see dbus-using processes spawn off short-lived dbus-daemon processes only if the session bus address is completely unset
[14:03] <desrt> whcih, of itself, is sort of unexpected
[14:03] <ogra_> yeah
[14:03] <desrt> oh wait
[14:03] <desrt> you don't have X
[14:03] <desrt> so the autolaunch stuff tries to get the information out of X... which wouldn't work in your case
[14:04] <ogra_> aha !
[14:04] <desrt> but again -- it shouldn't do this if the variable is set...
[14:04] <ogra_> hmm, we used to use dbus-launch in the past
[14:09] <ogra_> desrt, well, the var is only exported to the upstart session ... not sure it ends up in the actual env during the startup
[14:09] <ogra_> that might explain why dconf behaves like this
[14:13] <desrt> ogra_: could also be a race here
[14:14] <desrt> maybe the environment variable doesn't get set until after all of the initial jobs have been fired up
[14:14] <ogra_> hmm
[14:14] <desrt> so later-started processes get it
[14:14] <desrt> but the early ones don't
[14:14] <desrt> a simple reading of how that script functions would seem to strongly suggest that, in fact
[14:15] <desrt> and this is part of why systemd is moving to socket-based activation of the dbus-daemon
[14:15] <ogra_> we have nothing that starts on "starting dbus" only on "started dbus"
[14:15] <ogra_> so th evar should be set
[14:15] <desrt> because otherwise you either need to serialise the entire startup on waiting for dbus-daemon or risk these kinds of races
[14:15] <desrt> ogra_: but what decides when dconf starts?
[14:15] <ogra_> dunno, you tell me :)
[14:15] <desrt> another process trying to use it
[14:16] <ogra_> oh, wait
[14:16] <desrt> unless you guys manually start it
[14:16] <desrt> i have no idea...
[14:16] <ogra_> that could be lightdm ...
[14:16] <desrt> lightdm doesn't get on the user's session bus
[14:16] <desrt> so that's unlikely
[14:16] <ogra_> we dont use a greeter ... but i can imagine the process still fires it up
[14:16] <desrt> oh.  this is the greeter session?
[14:17] <ogra_> well, the bootchart doesnt tell whose dbus it is :)
[14:17] <ogra_> we dont have a greeter session
[14:17] <ogra_> we use autologin
[14:17] <ogra_> but start unity-system-compositor from the usual greeter code
[14:17] <desrt> ogra_: if i were you, i'd figure out a way to serialise the entire session startup on dbus
[14:18] <ogra_> mterry, do you know if it could be that lightdm fires up dconf in the "greeter" on the phone ?
[14:18] <ogra_> thats what we essentially do
[14:18] <desrt> either take dbus-launch outside of the upstart world (ie: launch upstart from inside of dbus-launch, sort of like we did with gnome-session back in the day) or figure out a way to prevent upstart from doing __anything__ until the dbus job is fully complete
[14:18] <ogra_> nearly everything starts on started dbus or on something that starts on this event
[14:18] <mterry> ogra_, probably?
[14:19] <mterry> ogra_, reading above real quick, I will point out that once the split happens, dbus will be started before upstart for the greeter (not true for user session though)
[14:19] <ogra_> mterry, i'm trying to figure out why we have multiple dbus-daemons in http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-239.png
[14:19] <desrt> ogra_: could it be that 'started dbus' thinks that dbus is running once the dbus-daemon has established itself on the listener socket but before the initctl has published the variable?
[14:19] <ogra_> ... after lightdm runs init ...
[14:20] <mterry> ogra_, this is pre-split?  not sure
[14:20] <desrt> iirc you do some strange ptrace() stuff to watch for things like daemons listening on sockets in order to know about ready conditions
[14:20] <ogra_> mterry, this is from today, yes
[14:21] <mterry> looks like accounts-daemon is getting autostarted
[14:21] <mterry> for its own little dbus.  huh
[14:22] <ogra_> yeah, there are several dbus-daemons starting and dieing
[14:22] <ogra_> *dying
[14:23] <desrt> content-hub-pee
[14:24] <desrt> increase bootup speed by reducing washroom breaks of boot-time components?
[14:24] <ogra_> http://paste.ubuntu.com/7108376/
[14:24] <ogra_> thats the session dbus log
[14:25] <ogra_> first line looks interesting
[15:25] <tsdgeos> i guess getting lcms 2.6 on trusty is not possible?
[15:28] <seb128> tsdgeos, is that a bugfix version or new serie? how much change over 2.5 (which is what we have)
[15:29] <tsdgeos> seb128: "Version 2.6 is a featured release that introduces contexts, greatly improves concurrency and minimizes thread contention."
[15:30] <seb128> that would need a ffe then...
[15:30] <seb128> not sure how realistic that is or if anyone had a look
[15:30] <seb128> tkamppeter, ^ do you know about that?
[15:31] <tsdgeos> it's probably late, but without it programs using poppler and ghostscript in the same process will crash (at least okular does, not sure if/why evince doesn't)
[15:32] <seb128> tsdgeos, oh, why?
[15:32] <tsdgeos> seb128: because lcms has the concept of "global memory allocator" and gs sets it, and then when you unload libgs because you're not using it anymore, it's not unset :D
[15:32] <tsdgeos> 2.6 has the concept of "per plugin memory allocator"
[15:32] <tsdgeos> so all is nice and dandy
[15:32] <seb128> hum, k
[15:33] <seb128> well, I didn't evaluate it but that seems like a non trivial change for that late in the cycle
[15:33] <tsdgeos> maybe evince just doesn't unload libgs once loaded
[15:33] <tsdgeos> i may want to just do the same in okular
[15:37] <tjaalton> new lightdm lock screen doesn't allow to switch to another user anymore
[15:39] <seb128> tjaalton, it does through the session indicator, except that the unity team screwed the stacking while fixing alt-tab and dash sometime showing over the lock screen
[15:40] <seb128> so the indicators currently open behind the greeter
[15:40] <seb128> bschaefer, hey, are you working on fixing that ^? ;-)
[15:41] <tjaalton> ahah, ok :)
[15:41] <tjaalton> worth filing a bug still?
[15:41] <seb128> no
[15:41] <tjaalton> good
[15:41] <seb128> tjaalton, https://bugs.launchpad.net/ubuntu/+source/unity/+bugs?field.tag=lockscreen
[15:42] <tjaalton> thanks
[15:43] <bschaefer> seb128, hmm well yeah, but its been a problem for as long as nux has been around :(
[15:44] <bschaefer> seb128, it was the issue with the fullscreen windows
[15:44] <bschaefer> and the locker, as nux assumes all windows to be DOCK type so Fullscreen window stack above it etc etc... == annoying issue :(
[15:44] <seb128> bschaefer, well, if it turns out we can't implement a secure lock screen with what we have I guess we need to go back to use gnome-screensaver :/
[15:44] <bschaefer> seb128, im looking at a fix but yeah
[15:45] <bschaefer> seb128, worst case, we could have fullscreen windows cause indicator issues only ... not ideal
[15:54] <tkamppeter> seb128, I did not know that.
[15:55] <tkamppeter> seb128, tsdgeos, but as it is needed to prevent okular from crashing we should really consider and FFE here.
[15:55] <tsdgeos> tkamppeter: i can give you some pointers if you want
[15:56] <seb128> tkamppeter, well, there might be another fix/workaround as well
[15:58] <Laney> Not unloading the plugin is a workaround
[15:59] <tsdgeos> sure i already said that
[15:59] <tsdgeos> but then people complain kde uses too much memory ^_^
[16:00] <tsdgeos> tkamppeter: but since it would probably need a new gs release too, i'll have to do that
[16:00] <tsdgeos> one thing is updating lcms and the other gs
[16:04] <Laney> It makes me nervous
[16:34] <ritz_> tkamppeter, do you work with openprinting ?
[16:35] <ritz_> seen from https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-common-printing-dialog
[16:37] <Laney> Sweetshark: is https://bugs.launchpad.net/ubuntu/+bug/1286216 done?
[16:37] <ubot2> Launchpad bug 1286216 in Ubuntu "[needs-packaging] [FFE] new package libreoffice-dictionaries" [Wishlist,Confirmed]
[16:48] <tkamppeter> ritz_, yes, I am leading the OpenPrinting project.
[17:07] <ritz_> tkamppeter, the print dialog spec are not working http://wiki.openusability.org/printing/index.php/Specification
[17:07] <ritz_> 404
[17:07] <ritz_> reachable from https://wiki.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialog
[17:07] <ritz_> I was looking at https://live.gnome.org/GnomeOS/Design/Whiteboards/Printing
[17:07] <ritz_> this lack any input for auth
[17:08] <ritz_> context - working on bugs.launchpad.net/bugs/959451 . was trying to see how to implement this
[17:11] <Sweetshark> Laney: yes: https://launchpad.net/ubuntu/+source/libreoffice-dictionaries -- closing the bug, thanks for the hint.
[17:11] <ritz_> tkamppeter, inputs welcome
[17:11] <Laney> ty
[17:12] <ritz_> Sweetshark, hi, https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1200277
[17:12] <ubot2> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Medium,Fix committed]
[17:12] <ritz_> Sweetshark,  how easy is it to include this fix in precise, and lo ppa ?
[17:15] <ritz_> Sweetshark, nm, I am daft
[17:17] <Sweetshark> ritz_: its in the ppa already for 4.2 builds -- I assume the precise backport have it too. The fix is also in the libreoffice-3-5 ppa for precise and could be SRUed into precise/main.
[17:18] <ritz_> Sweetshark++  thanks :)
[17:37] <tkamppeter> ritz_, unfortunately, the Common Print Dialog project of OpenPrinting has died, due to lack of funding or volunteer coders. In the end I got even Canonical to fund a part which led them to hire larsu, but the other part was supposed to be carried by a German government organization, who originally wanted to fund it, but when Canonical kicked in and I wanted to get everything together, no one at the German government organization an
[17:37] <tkamppeter> swered my e-mails any more, the project died due to this, I proposed the new functionality of the Common Print Dialog to the existing print dialogs, some features at least got implemented, and larsu got put on other work.
[18:08] <seb128> Laney, new icons coming for uss, http://people.canonical.com/~seb128/settings.png
[18:08] <seb128> just as a preview ;-)
[18:09] <Laney> are they bigger?
[18:09] <Laney> also, that green...
[18:09] <seb128> yes
[18:09] <seb128> well, green is me who picked on variant
[18:10] <seb128> we are supposed to go dynamic and have all the variants used accorded to the status
[18:10] <davmor2> seb128: ohhhh pretty
[18:10] <seb128> Laney, http://people.canonical.com/~seb128/settingsiconsvariant.png
[18:10] <seb128> I still don't like that theme :-/
[18:10] <Laney> me neither
[18:10] <Laney> having one thing coloured like that attracts your attention
[18:10] <Laney> (going back to the first one)
[18:11] <Laney> I prefer it without the frames too, but maybe that's me
[18:11] <davmor2> seb128: ouch that hurt my eyes
[18:12] <seb128> that's the design
[18:12] <seb128> http://people.canonical.com/~seb128/settings-menu.png
[18:13] <seb128> in fact it's slightly better with the bg color on the icons
[18:13] <seb128> http://people.canonical.com/~seb128/settingscolor.png
[18:13] <seb128> but still not great
[18:13] <Laney> what's that previous one?
[18:13] <seb128> the "settings-menu.png"?
[18:13] <Laney> yes
[18:13] <seb128> that's the design mockup
[18:14] <Laney> I see
[18:15] <Laney> I like https://wiki.ubuntu.com/SystemSettings?action=AttachFile&do=get&target=phone-settings.mockup.png more with respect to the colours on the battery icon
[18:15] <Laney> have you tried the larger icons on the phone?
[18:15] <seb128> not yet
[18:15] <seb128> I was just validating the icons for tiheum
[18:16] <seb128> they are in https://code.launchpad.net/~tiheum/ubuntu-themes/suru-icons/+merge/211378 now, I put a landing ask for those
[18:16] <Laney> do they think the actual screenshot with the dark theme looks good?
[18:16] <seb128> I'm going to play more with the settings change tomorrow and propose that
[18:16] <Laney> rather than a mockup
[18:17] <seb128> he said my screenshot was good
[18:17] <seb128> but I think it was more validating that it matches the design
[18:17] <seb128> I plan to not change the theme until they force me into doing it though :p
[18:18] <Laney> mmm
[18:19] <Laney> I'd like to push back on the coloured battery icon :(
[18:19] <Laney> and ideally the frames until we change theme
[18:19] <Laney> they look alright in the mockup but I don't like it in the light theme
[18:19] <seb128> right, the frames were to try to get something close to the design to validate the icons
[18:19] <Laney> did you implement a dynamic icon for battery?
[18:19] <Laney> that'd be cool actually
[18:19] <seb128> no
[18:20] <seb128> indeed
[18:20] <seb128> well they said we should have dynamic for all icons that are indicators
[18:20] <Laney> it already has a plugin for the entry component so you should be able to do it
[18:20] <seb128> the blue battery is going to be in the panel as well
[18:20] <seb128> yeah
[18:20] <seb128> I can have a look tomorrow
[18:20] <Laney> bah, why
[18:20] <Laney> monochrome is nice there
[18:21] <seb128> it is
[18:21] <seb128> I can understand red for low battery
[18:21] <seb128> but the blue for charged seems pointless
[18:21] <Laney> when you need to take action
[18:21] <Laney> like when the session indicator turns red
[18:21] <Laney> that's fine
[18:21] <seb128> right
[18:23] <Laney> Would be nice if these requests happen in public so that I could comment
[18:23] <Laney> anyway, /me approves libimobiledevice & goes off to climb
[18:31] <seb128> Laney, have a nice evening!
[18:31]  * seb128 off for the evening as well
[18:31] <seb128> time for sport
[20:43] <tkamppeter> jasoncwarner, hi
[21:01] <mterry> cyphermox, we don't allow connecting to new networks in unity-greeter, right?
[21:02] <cyphermox> mterry: not that I know, no. it's lock down at that point
[21:02] <mterry> cyphermox, OK thanks.  The touch config package will have to poke polkit holes
[21:02] <cyphermox> possibly?
[21:02] <cyphermox> I expect not much though
[21:03] <cyphermox> it's working in desktop it should be almost instantly working in touch too for this
[21:58] <mterry> robert_ancell, good morning!
[21:58] <robert_ancell> mterry, hiya
[21:58] <mterry> robert_ancell, I saw you took the branch.  I tested on my machine with split branches and all that goodness.  Works great in Mir.  Didn't seem to screw up my desktop either
[21:58] <robert_ancell> yeah, running it here, seems to work well
[21:59] <mterry> But I didn't run it much on desktop.  Only risk factor would be that we re-set the active session.  But that should always be in sync with VTs on desktop anyway
[21:59] <mterry> I would think...
[21:59] <mterry> Especially since opening a new session changes VTs
[22:00] <mterry> or at least it can