[05:36] <pitti> Good morning
[09:01] <seb128> good morning desktopers
[09:05] <Laney> hello!
[09:05] <seb128> Laney, hey, happy friday!
[09:05] <Laney> hey seb128 (& pitti), happy friday to you!
[09:05] <Laney> nice and sunny here
[09:05] <seb128> grey and windy here
[09:06] <seb128> it was nice and sunny yesterday
[09:06] <seb128> give it back!
[09:07] <Laney> http://www.bbc.co.uk/weather/2641170
[09:07] <Laney> i think you can have it in 5-6 hours :P
[09:07] <seb128> lol
[09:08] <seb128> http://www.meteofrance.com/previsions-meteo-france/metz/57000
[09:08] <seb128> seems like we are just getting the rain :/
[09:08] <Laney> mmm, bad weekends for us
[09:10] <seb128> nice, robert_ancell fixed the "can't type password on the greeter" bug in unity-greeter
[09:12] <Laney> great
[09:22] <pitti> hey Laney, bonjour seb128
[09:23] <pitti> nice & sunny here too, already 20 degrees
[09:23] <seb128> pitti, hey, wie gehts? happy friday!
[09:23] <pitti> what a great start of spring :)
[09:23] <pitti> seb128: quite fine, thanks!
[09:23] <Sweetshark> Moin!
[09:24] <pitti> moin Sweetshark, frohen Fruehlingsanfang!
[09:27] <seb128> pitti, lucky you
[09:27] <seb128> pitti, http://www.meteofrance.com/previsions-meteo-france/metz/57000 is what we get :/
[09:28] <pitti> seb128: :(
[09:29] <pitti> seb128: mais il sera mieux la semaine prochaine
[09:30] <seb128> pitti, oui
[11:30] <Saviq> can someone please make bug #1200270 public?
[11:31] <seb128> Saviq, done
[11:32] <Saviq> seb128, thanks
[11:32] <seb128> oh, nice
[11:32] <seb128> I just hit that this morning
[11:32] <seb128> or similar, a compiz segfault in libframe
[11:34] <Saviq> freakin 24° in March...
[11:35] <ogra_> yeah
[11:35] <ogra_> unbelivable
[11:36] <ogra_> Saviq, you guys at least had some winter  over there ...
[11:36] <ogra_> we didnt ... not even below zero
[11:36] <Saviq> ogra_, the New Yorkers stole all the winder
[11:36] <ogra_> europe will get eaten by insects this summer
[11:36] <Saviq> *winter
[11:46] <mdeslaur> seb128: hrm, seems some people are having a regression, but I can't reproduce it..
[11:46] <mdeslaur> seb128: http://askubuntu.com/questions/436385/segmentation-fault-when-installing-librsvg2-common-and-libgdk-pixbuf2-0
[11:46] <mdeslaur> seb128: https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1174253
[11:46] <ubot2> Launchpad bug 1174253 in gdk-pixbuf (Ubuntu) "Segfault (core dumped) in gdk-pixbuf on upgrade" [Undecided,Confirmed]
[12:02] <seb128> mdeslaur, hum :/
[12:03] <seb128> mdeslaur, nessita has the issue on a precise box some days ago, but she had a glib 2.37 from a ppa (where precise has 2.32) so we though it was due to the ppa, maybe it was not
[12:03] <seb128> mdeslaur, http://pastebin.ubuntu.com/7119828/ was the stacktrace she had
[12:06] <seb128> mdeslaur, looking to the gtk diff it's weird that it leads to those issues :/
[12:08] <mdeslaur> seb128: not sure what gtk+3.0 has to do with that stacktrace...
[12:08] <seb128> mdeslaur, nothing, that's what said
[12:09] <mdeslaur> the only thing I can think of is that the librsvg update triggered gdk-pixbuf in the postinst
[12:09] <seb128> mdeslaur, when you say regression it implies change, but gdk-pixbuf didn't change?
[12:09] <mdeslaur> nope, it didn't
[12:10] <mdeslaur> but librsvg does this:  dpkg-trigger --no-await /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/*/loaders
[12:12] <mdeslaur> so perhaps their gdk-pixbuf was already broken, and the update just triggered it
[12:12] <seb128> yeah
[12:12] <seb128> did we get many reports?
[12:12] <seb128> I didn't see any out of the one I pointed you at yesterday
[12:12] <mdeslaur> no, just the bug you showed me yesterday, and 3-4 people adding me-toos to the old gdk-pixbuf bug
[12:12] <seb128> k
[12:12] <Laney> actually
[12:12] <mdeslaur> so it doesn't seem widespread
[12:13] <Laney> I can get that if I install librvg2-common in a precise-chroot then upgrade librsvg2-common libglib2.0-0 to raring
[12:13] <Laney> which is what the original reporter of that bug had
[12:13] <seb128> oh, interesting
[12:14] <seb128> the loader is in common
[12:14] <mdeslaur> Laney: hrm, interesting...which resembles what nessita had too, an updated glib
[12:14] <seb128> Laney, does that upgrade the lib with it?
[12:14] <seb128> mdeslaur, can the lib and -common (=loader) get out of sync?
[12:14] <mdeslaur> seb128: ?
[12:15] <seb128> mdeslaur, what happen if you update librsvg2-common (that has the gdk-pixbuf loader)
[12:15] <Laney> yes it updates the library
[12:15] <seb128> mdeslaur, does that pull in the new lib?
[12:16] <seb128> hum, ok, so it's not those getting out of sync :/
[12:16] <seb128> I though maybe we would get the new loader with the old lib
[12:16] <Laney> i can't get it within precise
[12:17] <seb128> do you get it if you upgrade glib and not librsvg2-common?
[12:17] <seb128> glib to raring
[12:17] <seb128> e.g is that old librsvg and new glib which is the issue?
[12:17] <Laney> sec, checking if it happens in a supported upgrade path
[12:18] <mdeslaur> it may be just a side effect of the trigger in the librsvg postinst, and have nothing to actually do with librsvg itself
[12:18] <Laney> I expect that's the case
[12:18] <Laney> you can get it if you run gdk-pixbuf-query-loaders
[12:18] <mdeslaur> yeah
[12:18]  * mdeslaur wait impatiently for real hardware to finish installing
[12:19] <Laney> bah, yeah, it happens on trusty upgrade too
[12:20] <seb128> oh
[12:20] <seb128> Laney, same bt?
[12:20] <Laney> sec
[12:21] <Laney> just upgrading glib is enough
[12:21] <seb128> deeeeesssssrrttt
[12:22] <seb128> Laney, btw on a similar not, https://errors.ubuntu.com/problem/51867c7babfc41c749a4ed34ba54148f534a28c1 is ranked high on trusty issue and is also a segfault on precise->trusty updates
[12:23] <seb128> bug 1272977
[12:23] <ubot2> Launchpad bug 1272977 in gtk+3.0 (Ubuntu) "gtk-update-icon-cache segfaults in gdk_pixbuf_io_init()" [High,Triaged] https://launchpad.net/bugs/1272977
[12:24]  * seb128 hates in session upgrades
[12:26] <Laney> http://paste.ubuntu.com/7130341/
[12:27] <seb128> seems like the dlopen fails?
[12:27] <seb128> _dlerror_run
[12:28] <seb128> errstring = 0x10101010000007c <error: Cannot access memory at address 0x10101010000007c>
[12:30] <mdeslaur> ugh
[12:30] <mdeslaur> https://launchpad.net/~webupd8team/+archive/gvfs-libmtp
[12:30] <mdeslaur> that ppa installs an updated glib on precise
[12:30] <seb128> it's not the only one
[12:31] <mdeslaur> seb128: you're scaring me :)
[12:32] <seb128> lol
[12:32] <seb128> well, nessita has 2.37 from a scope testing ppa (though a private one)
[12:32] <seb128> we can't do a lot to prevent ppa users to run into issues...
[12:32] <seb128> we should look at the precise->trusty upgrade issue though
[12:35] <mdeslaur> seb128, Laney: thanks for your help
[12:35]  * mdeslaur feels better now
[12:35] <seb128> mdeslaur, I didn't do much, but yw!
[12:35] <Laney> at least we found a bug in trusty upgrades
[12:35] <Laney> I wonder how we didn't notice it in raring
[12:36] <seb128> I wonder if it's the same as the gtk-update-icon-cache one
[12:36] <Laney> I don't get that
[12:36] <Laney> not in this partially upgraded state anyway
[12:36] <seb128> well, e.u.c suggest a lot more users get that one that the one you are getting
[12:36] <seb128> it's concerning that a glib update makes gdk-pixbuf segfault though
[12:37] <seb128> glib is supposed to be ABI compatible
[12:37] <seb128> let's see if desrt have a clue what could be going on there
[12:37] <Laney> yeah if you upgrade gdk-pixbuf it goes away
[12:37] <Laney> that probably happens on upgrades
[12:38] <seb128> we can avoid it, but still updating glib should make gdkpixbug segfault
[12:39] <Laney> should *not* :P
[12:40] <seb128> yeah, I need to stop forgetting the not :p
[12:53] <seb128> on the list of frequent trusty issue as well
[12:56] <seb128> software-center hitting
[12:56] <seb128>  The following packages have unmet dependencies:
[12:56] <seb128> steam-launcher: Depends: jockey-common but it is not going to be installed
[12:56] <seb128>                 Depends: libc6 (>= 2.15) but 2.19-0ubuntu2 is to be installed
[12:56] <seb128>  
[12:56] <seb128> is steam-launcher something we ship/provide?
[12:57] <seb128> oh
[12:57] <seb128> https://apps.ubuntu.com/cat/applications/steam-launcher/
[12:59] <Laney> it's not in the archive
[12:59] <Laney> s-c wants me to 'Buy' it... where do those come from?
[13:21] <bregma> seb128, I've been testing a bunch of lockscreen fixes in landing-006, and everything is fine on one of my test machines but another one has trouble after switching to the guest session fro the lockscreen: bschaefer could not reproduce, could I get you to also test it for me, in case I just have a messed-up test machine?
[13:23] <seb128> bregma, hey, sure
[13:36] <seb128> bregma, what specific issue do you have? seems to work fine me, I switched forth and back a few time between my user and a guest using the indicator, no problem (out of the "screen lock dialog is displayed for your user when coming from the greeter", which is not a new issue)
[13:37] <bregma> (1) my mouse disappears when switching to the guest (I have a touchscreen, so I'm not completely hosed) and (2) when I switch back to my own session, the lockscreen comes up for the guest account (at which point I am hosed, because there is no password)
[13:37] <bregma> but only on my one machine
[13:38] <bregma> so I do suspect something weird on that machine
[13:38] <seb128> how do you go back your session?
[13:38] <bregma> I touch the menu option in the sesson menu
[13:38] <seb128> but yeah, I can't even imagine how your user-session-process-unity would ask you to unlock for guest
[13:39] <seb128> are you sure are on the right vt?
[13:39] <seb128> tried to ctrl-alt-f7?
[13:45] <bregma> the only graphics vt is vt7, and if I switch to the guest session without the lockscreen on, switching back to my session always gives me the guest session after flashing my session briefly on the screen
[13:46] <seb128> it looks like lightdm or something nuked your user session and put the guest on that vt
[13:46] <seb128> do you play with Mir/system compositor on that box?
[13:46] <bregma> it's possibly I have a messed-up lightdm config
[13:46] <seb128> well anyway, I doubt it's unity's doing
[13:46] <seb128> I fail to see how unity could lead to that
[13:47] <seb128> so +1 from me for publishing the silo to the archive ;-)
[13:47] <bregma> agreed, thanks for conforming the problem is on my end
[13:47] <seb128> yw, always happy to help landing bugfixes ;-)
[14:11] <desrt> seb128, Laney, anyone: does anyone know the gcc bug that means g_return_if_fail() return types are mismatched?
[14:12] <seb128> desrt, is that the one larsu mentioned? no...
[14:12] <desrt> ah.  i thought one of you guys told me about it
[14:12] <desrt> maybe it was larsu :)
[14:14] <seb128> desrt, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1234218
[14:14] <ubot2> Launchpad bug 1234218 in gcc-4.8 (Ubuntu) "4.8 doesn't throw -Wreturn-type anymore for wrong returns in macros" [Undecided,New]
[14:14] <seb128> desrt, that one?
[14:15] <desrt> yes.  thanks.
[14:15] <desrt> erm
[14:15] <desrt> no upstream link
[14:15] <desrt> is it possible that nobody has actually reported this issue to gcc? :)
[14:17] <seb128> desrt, could be
[14:18] <seb128> desrt, larsu is off today
[14:35] <ritz> chrisccoulson, hi, is it possible to update to tb 24.4.0 on precise , or do I need to file an sru on this ?
[14:35] <ritz> wrt https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1281887
[14:35] <ubot2> Launchpad bug 1281887 in thunderbird (Ubuntu) "upgrade thunderbird to 24.4.0" [Undecided,New]
[15:00] <ritz> seb128, could we mark this as wont fix against precise ? https://bugs.launchpad.net/ubuntu/precise/+source/vino/+bug/1027086
[15:00] <ubot2> Launchpad bug 1027086 in vino (Ubuntu Precise) "incorrect schema setting used for authentication-methods in vino server" [Medium,In progress]
[15:02] <ritz> Sweetshark, hi, wrt http://bugs.launchpad.net/bugs/1200277 . is there an ETA ?
[15:02] <ubot2> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Medium,Fix committed]
[15:02] <ritz> for precise and trusty
[15:04] <Guest19431> can i install gnome3.10 in ubuntu12.04 by any means?
[15:04] <seb128> ritz, why? I put it triaged/low in case somebody wants to come with a proper solution
[15:05] <seb128> Guest19431, try #ubuntu for user questions, and probably not
[15:05] <Guest19431> seb128, sorry i m new here
[15:06] <ritz> seb128, upstream believe, the correct fix is as posted
[15:06] <ritz> and to for bad inputs to generates warning.
[15:06] <seb128> ritz, so why wontfix?
[15:07] <ritz> seb128, difference of opinion between what is supposed to be the correct fix, and what the upstream believes is the correct fix
[15:08] <seb128> ritz, k, it's not important enough for me to try to argue more over it, let's keep it as triaged/low
[15:08] <ritz> seb128, fair point. this has been fixed in raring and above ( with upstream)
[15:08] <ritz> leaving precise as it is
[15:09] <seb128> k
[15:23] <Sweetshark> ritz: for the archive: trusty in the next days. precise: if needed we can make an SRU extra for that, otherwise: when something else shows up ...
[15:23] <ritz> Sweetshark, thank you :)
[15:24] <Sweetshark> ritz: Do we need a precise SRU?
[15:24] <ritz> Sweetshark++ seb128++
[15:31] <chrisccoulson> ritz, no need to report a bug, it will get updated when i have time. it's not particularly urgent
[15:32] <ritz> chrisccoulson, thanks , I will remove the ubuntu-sponsor from the subscriber
[15:39] <Trevinho> seb128: hey, for unity scaling changes have you got some time to check https://code.launchpad.net/~3v1n0/unity-control-center/applications-scaling-selector/+merge/212114 ?
[15:40] <Trevinho> seb128: there are probably some strings to improve
[15:45] <seb128> Trevinho, hey, not really, maybe in some hours, I've like 10 things on my todo for the day
[15:45] <Trevinho> seb128: ok, np
[15:46] <seb128> Trevinho, do you have a screenshot? ;-)
[15:46] <Trevinho> seb128: in a sec
[15:47] <seb128> Laney, ^ do you have spare cycle/want to help with that maybe? (not sure what you got on your plate to end this friday ;-)
[15:47] <Trevinho> seb128: http://imgur.com/brK7lQN
[15:48] <Laney> I think you should ask mpt to review the approach and strings
[15:48] <Laney> Applications Scale target is surely going to need work :P
[15:48] <Laney> but yeah, can look at the code in a bit
[15:49] <Trevinho> Laney: yeah, consider the strings a stub
[15:49]  * Trevinho can't word things .P
[15:49] <Trevinho> seb128, Laney and http://i.imgur.com/X7ob0sC.png
[15:49] <Trevinho> also for Use {max,min}...
[15:50] <seb128> Trevinho, I don't understand what those options mean :p
[15:50] <Trevinho> it's probably better to just to add Use Max available scale and... "Never scale apps"...
[15:50] <Trevinho> seb128: that's why I said strings need work :D
[15:50] <Laney> do you think those ones are required?
[15:50] <Laney> I just imagined listing the monitors and a never one
[15:50] <seb128> Trevinho, in the UI still fitting on a netbook vertical resolution?
[15:51] <Trevinho> seb128: eheh, btw well. they means to use the min or max scale values acrosso monitors
[15:51] <Trevinho> seb128: mh, the window is 661px...
[15:52] <Trevinho> height
[15:52] <seb128> Trevinho, so doesn't fit on 1024x600 which netbooks use
[15:52] <Trevinho> seb128: i would loved to remove some padding above the UI scale, but I wasn't able :P
[15:52] <seb128> we have lot of space on the right :p
[15:53] <Trevinho> seb128: mh, I would have used that as well... but I didn't want to beak the actual way to dispose things
[15:53] <Trevinho> let me see what I can do
[15:59] <mpt> “UI scale” and “Applications Scale target”? Yer what?
[16:00] <mpt> I don’t know what “Use maximum monitor scale” means either :-(
[16:00] <Laney> I'm not sure those are necessary
[16:00] <Trevinho> mpt: well, wording must be improved absolutely.. I just left the first "dev stinrgs" there...
[16:01] <Trevinho> mpt: max,min: means use for all the applications the {max,min} ui sale set per monitor
[16:01] <Laney> the monitor with the largest scaling factor
[16:02] <Trevinho> mpt: btw actually we should instead just add: "Use the monitor with largest scaling factor" or... "Never scale applications".
[16:02] <Trevinho> don't caring about the minimum value....
[16:02] <mpt> What do you mean by “Use the monitor”? Would that move all windows to that display?
[16:03] <Laney> for the "Application scaling"
[16:03] <Laney> vs UI scaling
[16:03] <Trevinho> mpt: no, the fact is that the UI scale, when it comes to toolkits, is not per monitor basis
[16:03] <Trevinho> mpt: but a global value
[16:03] <mpt> Trevinho, sure, I wrote <https://wiki.ubuntu.com/BrightnessAndDisplays#Scaling>
[16:03] <mpt> so I understand that part at least :-)
[16:04] <Trevinho> so, to we need the user to define what scaling to use at global level
[16:04] <Trevinho> ok...
[16:04] <Trevinho> :)
[16:04] <mpt> So which of the three settings would “Use maximum monitor scale” change, and to what?
[16:04] <Trevinho> ah, I didn't see the new diesngs
[16:04] <Laney> that even has a two column layout
[16:05] <mpt> Trevinho, I understand that this menu is a quick placeholder for 14.04
[16:06] <mpt> I guess “UI scale” maps to ui-scale, that much is obvious :)
[16:08] <Trevinho> mpt: yeah, but let me see because probably I can adjust the things to match design more...
[16:09] <mpt> Laney, yeah, that was to solve the issue where we currently have three rows of stuff for the current display, followed by two rows of display-independent stuff, followed by one row of stuff for the current display, followed by one more row of display-independent stuff
[16:11] <Laney> mpt: yeah, but it also solves another problem in that the UI becomes too tall for netbook-like screens if we keep growing downwards
[16:11] <Laney> I'm all in favour of implementing more of that design if it's reasonable to do so in fairly short order
[16:12] <Trevinho> Laney: good
[16:12] <Trevinho> mpt: there's just one thing the "Scale of r menu and title bars" can't be called in that way, since it will only apply to Shell elements
[16:13] <Trevinho> so to panel, decorations, launcher... but no menu
[16:13] <mpt> Trevinho, the menu bar isn’t a shell element??
[16:14] <Trevinho> mpt: menu bar yes... but no menu content.. I mean, I know you're talking of "bars", but I don't want it to might be considered as it includes also the menu themselves
[16:14] <mpt> Trevinho, I understand that it will change the size of menus that come down from the menu bar, but not context menus or popup menus etc
[16:14] <mpt> Is that right?
[16:14] <Trevinho> mpt: no :(
[16:15] <Trevinho> mpt: the menus won't scale,
[16:15] <mpt> oh crikey
[16:15] <mpt> So the menu contents will be smaller/larger than the menu titles?
[16:15] <Trevinho> mpt: at least, it *might* be possible to achieve... but not done yet
[16:15] <Trevinho> it can happen now yes
[16:15] <mpt> haha
[16:15] <mpt> ok
[16:15] <Trevinho> let me think...
[16:17] <mpt> It’s okay for those labels not to be exhaustive, they have what lawyers call a “penumbra” where you can guess what other sorts of things will be affected
[16:17] <Trevinho> mpt: mh, I don't think that the gtk-text-scale factor can be applied to only one widget... Laney?
[16:17] <mpt> …from the examples given. For example, I think the Windows equivalent of this setting refers to “menus and dialogs”, not needing to mention that it affects lots of other things too.
[16:18] <mpt> And I left out the Launcher because I wanted to avoid confusion with the Launcher’s separate size control (though this setting does affect the Launcher too).
[16:18] <Trevinho> yeah, right
[16:19] <Trevinho> why not just "scale for panels"?
[16:19] <mpt> Trevinho, would you be happy with “Size for menu bar and title bars”? That doesn’t claim that menu bar *menus* will change size too (though it would be nice if they did).
[16:20] <Trevinho> mpt: ok, that's fine... :)
[16:20] <mpt> cool
[16:21] <mpt> (We don’t use the term “panels” anywhere in the UI or help, afaik, but we do use “menu bar” in several areas of System Settings)
[16:21] <Trevinho> mpt: btw the settings I added where considering also another fact: how to handle things when new monitors are attached...
[16:21] <Trevinho> mpt: I mean, what to do: resize the APPS to default scale, or no?
[16:21] <mpt> Trevinho, you mean resize apps on all displays to match the ui-scale of the newly-detected display?
[16:22] <Trevinho> mpt: yes
[16:22] <Trevinho> mpt: or keep things big as in the "current" dpy?
[16:22] <Trevinho> (let's imagine we're on an hidpi laptop)
[16:22] <mpt> Trevinho, would that also mean changing them back automatically when the display is disconnected?
[16:23] <Trevinho> mpt: yes
[16:23] <Trevinho> mpt: that's happening right now..
[16:24] <Trevinho> mpt: err, for now the option in unity is to always apply the maximum scaling factor available in monitors to apps... But that can be falsified easily
[16:24] <mpt> Trevinho, what do you mean by “falsified”?
[16:25] <seb128> desrt, do you have any idea why old gdk-pixbuf would hit http://paste.ubuntu.com/7130341/ when running with a new glib (e.g precise gdk-pixbuf running with glib > 2.36 (instead of 2.32))
[16:25] <Trevinho> mpt: that there's an option that can be set to false to globally use the normal scale factor instead
[16:26] <mpt> Trevinho, by “normal” do you mean 1? Or something else?
[16:26] <Trevinho> mpt: 1, or just the minimum value available across monitors
[16:27] <desrt> seb128: yes.
[16:27] <desrt> the old loader query program didn't use gobject
[16:27] <desrt> but many of the loaders themselves did
[16:28] <desrt> so gobject would get loaded and unloaded repeatedly, each time a loader was queried
[16:28] <desrt> even if the query function didn't use it
[16:28] <desrt> upstream gdkpixbuf links -lgobject explicitly to avoid this
[16:28] <desrt> but as-needed linker flags circumvent that
[16:28] <desrt> so we added an explicit g_type_ensure(G_TYPE_OBJECT) to circumvent the circumvention
[16:28] <seb128> Laney, mdeslaur: ^ fyi
[16:29] <mpt> https://wiki.ubuntu.com/BrightnessAndDisplays?action=diff&rev2=11&rev1=10
[16:30] <desrt> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=686822
[16:30] <ubot2> Gnome bug 686822 in gobject "possible dlopen()/dlclose() issue with automatic g_type_init()" [Normal,Resolved: fixed]
[16:31] <seb128> desrt, I'm unsure to understand why updating glib leads to a segfault there?
[16:31] <desrt> fixed since late 2012... must be some very old gdk-pixbuf you have there
[16:31] <mpt> Trevinho, so when it’s false, you have *scale-factor = 1. When it’s true, you have *scale-factor automatically matching the ui-scale of … what? Whichever remaining display was connected last?
[16:31] <seb128> desrt, it's 12.04 dude
[16:31] <desrt> seb128: the difference is that new glib does g_type_init() automatically on module load
[16:31] <desrt> the module was always being improperly loaded/unloaded before
[16:31] <desrt> but it did no harm
[16:31] <seb128> so we should backport https://bug686822.bugzilla-attachments.gnome.org/attachment.cgi?id=227203
[16:31] <seb128> ?
[16:32] <desrt> yes
[16:32] <desrt> or stop using as-needed
[16:32] <seb128> thanks
[16:32] <seb128> desrt, I'm glad you replied, would have taken ages to figure out what was happening there
[16:32] <desrt> seb128: it took me ages to figure it out the first time ;)
[16:32] <seb128> mdeslaur, do you want to security update that, or should I just SRU it?
[16:33] <seb128> Laney, or maybe you want to do the SRU? you had a chroot/test setup to reproduce it
[16:33] <mdeslaur> seb128: sru it please
[16:33] <Laney> yeah I can cherry-pick that easily
[16:33] <Laney> do you have the bug report to hand?
[16:34] <seb128> Laney, bug #1174253
[16:34] <ubot2> Launchpad bug 1174253 in gdk-pixbuf (Ubuntu) "Segfault (core dumped) in gdk-pixbuf on upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/1174253
[16:34] <Laney> ty
[16:36] <desrt> i love g_type_ensure
[16:36] <desrt> it's such a tricky function
[16:36] <desrt> such a devious implementation
[16:38] <Trevinho> mpt: oh I missed the msg, sorry. But when false it uses the scale-factor that matches the lower value across all available monitors (probably to revert and just use always 1). When true it uses the scale factor that matches the UI scale of the connected monitor that has the maximum UI scale value
[16:39] <Laney> could you use the slider as per the design?
[16:40] <mpt> Trevinho, but that would mean there is no setting for “never touch the scale factor automatically”, right?
[16:41] <mpt> (evidence for the “boolean parameters considered harmful” theory)
[16:41] <Laney> boolean parameters considered harmful [x]
[16:42] <mpt> [_[ ON ]]
[16:57] <Laney> desrt: of course we don't have g_type_ensure in precise
[17:23] <Trevinho> mpt: no, but I might consider to just ignore the minimum thing, and use the default 1.0 instead
[17:35] <seb128> dobey, hey, is https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1244493 still on your list? trusty beta freeze is on monday
[17:35] <ubot2> Launchpad bug 1244493 in software-center (Ubuntu) "Software Center doesn't save settings on Saucy" [High,Confirmed]
[17:36] <jose> hey mterry, around?
[17:36] <mterry> jose, yes
[17:36] <jose> mterry: mind a quick PM?
[17:37] <mterry> jose, go crazy :)
[17:37] <dobey> seb128: ah, sorry. been dealing with click scope issues
[17:41] <seb128> dobey, no worry, I was just remind you in case you forgot about it ;-)
[17:47] <jose> hey guys! anyone from the desktop team has a minute? I'd like to make an invitation on behalf of the Classroom team
[18:10] <Laney> seb128: could you please do queue -Q unapproved -s precise-proposed reject 7198759 for me?
[18:11] <Laney> might make you give a reason too
[18:11] <Laney> which is 'laney sucks'
[18:12] <seb128> is that the oldest upload?
[18:12] <Laney> ya
[18:12] <seb128> I prefer https://launchpad.net/ubuntu/precise/+queue?queue_state=1 to the command line
[18:12] <Laney> do you use the web UI? ;-)
[18:12] <seb128> yeah
[18:12] <Laney> I see
[18:13] <seb128> so you went for LDFLAGS += -Wl,--no-as-needed
[18:13] <seb128> lgtm
[18:14] <seb128> Laney, rejected, thanks for the SRU!
[18:15] <Laney> yeah g_type_ensure doesn't exist in precise sadly
[18:17] <Laney> ok, time to go away
[18:17] <Laney> have a good weekend :-)
[18:21] <seb128> Laney, thanks, you too!
[19:20] <kenvandine> seb128, can you check my uss branch?
[19:20] <kenvandine> bill and i have tested it in the silo
[19:38] <seb128> kenvandine, yeah, -1 for it, please delete the silo
[19:39] <seb128> kenvandine, (that's the penalty for trying to do a friday upload)
[19:39] <seb128> kenvandine, ;-)
[19:39] <kenvandine> :)
[19:40] <seb128> kenvandine, ok, looks fine, I trust your testing so approved, enjoy ;-)
[19:42] <kenvandine> thx seb128
[19:42] <seb128> kenvandine, yw!
[19:42] <seb128> kenvandine, how is the testing going? getting it green for landing?
[19:42] <kenvandine> seb128, enjoy your weekend :)
[19:42] <kenvandine> yeah
[19:42] <seb128> kenvandine, thanks, you too
[19:42] <kenvandine> only complication is coordinating landing of gallery
[19:42] <kenvandine> since it's a click
[19:44] <chrisccoulson> good evening!
[19:49] <seb128> chrisccoulson, hey, how are you? are you still working?
[19:49] <chrisccoulson> seb128, yep, i'm always still working ;)
[19:49] <chrisccoulson> how are you?
[19:50] <seb128> chrisccoulson, or did you IRC from your phone drinking a beer at the pub? ;-)
[19:50] <chrisccoulson> lol
[19:50] <seb128> chrisccoulson, I'm good thanks ;-)
[19:51] <seb128> just back from dinner, drinking a glass of wine and chatting a bit on IRC before closing it and calling it a week ;-)
[19:51] <seb128> chrisccoulson, are you going to be in Malta?
[19:52] <chrisccoulson> seb128, i am, although i was going to join the apps week, but i'm on holiday the week prior to that so i'll be there in the second week ;)
[19:52] <seb128> chrisccoulson, that's great, you can hang out with us again ;-)
[19:53] <chrisccoulson> heh
[19:53] <seb128> we didn't see you for a while
[19:53] <chrisccoulson> i'm looking forward to having a non-US trip :)
[19:53] <seb128> you should come the first week and take holidays with some of us ;-)
[19:54] <chrisccoulson> heh, i've got a family holiday the week before that :)
[20:14] <chrisccoulson> oh, nice, i wanted to create a https server in python, and this blog post from pitti was the first hit in google: http://www.piware.de/2011/01/creating-an-https-server-in-python/ \o/
[20:14]  * chrisccoulson hugs pitti
[20:29] <JanC> chrisccoulson: just remember that it's not really a _full_ SSL/TLS server  :)
[20:30] <chrisccoulson> JanC, that's fine, I don't need one ;)
[20:30] <JanC> as long as you're aware of that it's fine :)
[20:32] <JanC> well, you and everybody else involved
[21:01] <sarnold> JanC: what's missing from this cute little simple server? :)
[21:02] <sarnold> I mean, I wouldn't expect e.g. SNI to work, but otherwise I'm curious where it could go wrong :)
[21:38] <Trevinho> mterry: hey, do you have some time to check https://code.launchpad.net/~3v1n0/unity-control-center/use-unity-text-scale-factor/+merge/212249 ?
[21:39] <mterry> Trevinho, uh sure
[21:39] <Trevinho> mterry: thanks
[21:43] <mterry> Trevinho, so what's the difference between the unity key and the other?  Like, why do we have our own key?
[21:43]  * mterry doesn't know history here
[21:45] <Trevinho> mterry: the fact is that when we have UI scale set in unity, it will scale (if set) the user applications mixing the text-scaling factor and the ui-scale factor from gtk (see https://wiki.ubuntu.com/BrightnessAndDisplays#Scaling), then at that point the gnome text scale factor might be changed....
[21:46] <Trevinho> then we need a place to store the actual text scale factor that we multiply to our scaling. Also in order to get a11y settings to work.
[21:47] <Trevinho> So we have our own setting now, that will be applied to the gnome text-scaling factor parameter by unity
[21:48] <mterry> Trevinho, so both the GNOME text-scaling-factor and the Unity text-scale-factor are both applied?
[21:50] <Trevinho> mterry: well, yes... I mean the gnome text-scaling-factor is used when scaling the UI in interrim values (i.e. you scale your UI at 1.5 or 1.75...), then if you set also the unity text-scaling-factor the gnome scaling factor will bump to the previous value * unity-text-scaling-factor
[21:51] <mterry> Trevinho, this is not making it clearer to me.  Maybe I'm too Friday'd
[21:51] <Trevinho> mterry: or more likely I'm explaing it not that well :)
[21:51] <Trevinho> mterry: so.... In UCC we now have a UI scale parameter... This parameter right now applies only to the shell; but we're changing it to apply also to system (if user wants).
[21:52] <Trevinho> mterry: to achieve that, since Gtk ui-scale-factor is only an integer, we play mixing it with the text-scaling-factor
[21:53] <mterry> Trevinho, So GNOME text-scaling-factor is an integer?  But Unity text-scale-factor is a double?
[21:53] <Trevinho> so if you've a UI scale set at 1.5, the gnome ui scale is 1, and the text-scale-factor 1.5... If the ui scale is 2.5, the gnome ui scsale is 2, and the text scale factor is 1.25
[21:53] <Trevinho> mterry: no, gnome text-scaling-factor is a double, but gnome UI.scaling-factor is an int
[21:54] <mterry> Trevinho, I'm just trying to figure out why we have our own version of GNOME's text-scaling-factor instead of using theirs
[21:55] <Trevinho> mterry: we use that, but we also use that for scaling the UI in general. But if an user changed the option to see "Big text" in a11y options, then that won't work... so here's why the new setting
[21:55] <Trevinho> that's also because in unity we scale things using cairo, and technically this saves us a lot of rewriting...
[21:56] <mterry> Trevinho, do I need another package to test this?  One with the scheme used?  I don't see that schema on my desktop (com.canonical.Unity.Interface)
[21:56] <Trevinho> mterry: yeah, I've linked the unity branch on the review
[21:56] <mterry> Trevinho, I still don't fully understand, but I'll trust that you folks do  :)
[21:56] <mterry> Trevinho, oh!  didn't see that
[21:57] <mterry> Trevinho, I don't believe you did link it?
[21:57] <Trevinho> mterry: I added it just after pinging you, so maybe you have been faster on loading the page
[21:57] <mterry> Oh, I refreshed
[21:57] <Trevinho> mterry: https://code.launchpad.net/+branch/~3v1n0/unity/scale-factor-binding
[21:58] <mterry> Trevinho, also, why does UCC cater to non-unity environments?  I figured we forked so we didn't have to  :)
[22:00] <Trevinho> mterry: yeah, in fact i wanted to ask about it... my initial commit was without checking unity env... Then I noticed that all the rest of the unity code was sitll doing it, so I was wondering it still had to be done
[22:00] <Trevinho> mterry: but if i can revert the change in a sec
[22:01] <Trevinho> err, ucc code I mean
[22:01] <mterry> Trevinho, I don't know myself, might want to check with seb128 about that.  But if rest of code does, I'd say go along with that and a purge merge could be made later
[22:01] <Trevinho> althuogh I was pretty sure it wasn't used in other envs, but... just to check
[22:05] <mterry> Trevinho, OK, code looks fine, but I just want to play with it myself.  Which means building unity.  So it'll take me a while, but I'll get there
[22:05] <mterry> Trevinho, unless there's urgency?
[22:05] <Trevinho> mterry: well we'd like to push unity now, with that in a silo... so if you want you can just wait the silo and then trying from the ppa
[22:06] <Trevinho> mterry: unity doesn't depend strictly on it, but I preferred to push them together not to break the user settings
[22:06] <Trevinho> mterry: also if that would happen only for people with HIdpi scale values
[22:06] <Trevinho> (i mean, the u-c-c- big text option wouldn't be considered)
[22:07] <mterry> Trevinho, ok, then I'll just approve.  Looks reasonable
[22:08] <Trevinho> mterry: thanks... I'll let you know when the ppa is ready
[22:09] <Trevinho> or bregma ^
[22:09] <mterry> Trevinho, done
[22:10] <Trevinho> mterry: ta