[06:51] <didrocks> good morning
[07:51] <seb128> hey didrocks, good morning desktopers
[07:52] <didrocks> re seb128
[07:52] <mardy> Saviq: hi! Now the unity8 indicators show up in the Ideapad s10-3t, but not much else: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1436203
[08:36] <willcooke> ahoy ship mates.
[08:36] <didrocks> morning capitains
[08:50] <seb128> hey willcooke
[08:50] <seb128> larsu, if you want some easy review karma, https://code.launchpad.net/~seb128/unity-settings-daemon/wrap-label-mount-dialog/+merge/253988
[08:51] <larsu> done
[08:51] <seb128> larsu, danke
[09:06] <willcooke> Folks, do you need anything from design in the next three months?  I've already made a list for them longer term, but just want to make sure I haven't missed any urgent requirements.
[09:07] <willcooke> Actually, I'll email this round too
[09:10] <seb128> willcooke, would be good to have a status update on the desktop theme refresh, and maybe converging a bit the icon theme (like using the touch indicator icons on desktop)
[09:11] <willcooke> great
[09:12] <willcooke> FJKong, You're still at NUDT right?
[10:54] <didrocks> it's like some people in the UK wrote this article: http://www.buzzfeed.com/marietelling/42-reasons-to-never-visit-france
[10:54] <didrocks> and btw…
[10:54] <didrocks> 28. Lyon is like an ugly wart in the middle of France.
[10:54] <didrocks> see, it's written "middle"
[10:54] <didrocks> :p
[10:55] <seb128> lol
[10:55] <didrocks> (funny that on this photo, you can see my engineering school)
[10:58] <didrocks> ahah, in the comments "zlatan agrees"
[11:14] <Sweet5hark1> larsu: most of hamburg  (at least from what I see) would agree with the berlin consensus. seems like after elbphilharmonie and BER airport, its Hamburgs turn again to have an opportunity to waste tax money into corruption ...
[11:15] <larsu> Sweet5hark1: yay! Gotta alternate wasting money ;)
[11:16] <Sweet5hark1> larsu: otoh its understandable: nobody knows if berlin will even have an airport finished in only 10 more years, so better not risk to have olympics there ...
[11:17] <larsu> clearly we won't
[11:17] <larsu> it's pretty hard to build an airport
[11:17] <larsu> not sure if _anyone_ has ever done that successfully
[11:20] <Sweet5hark1> larsu: if PAX are getting handed parachutes on final approach, requirements on the ground are easier to fulfill, I hear.
[11:20] <larsu> :D
[11:20]  * larsu <-- lunch
[11:23] <Sweet5hark1> "may the guys with beards, glasses and latte come to the front now please ? We start disembarquing over x-hain ..."
[11:25] <Sweet5hark1> seb128: whats your take on doing an libreoffice upload for kde themeing? the patch seems innocent enough to me ...
[11:25] <seb128> Sweet5hark1, should be ok I think
[11:25] <seb128> but I'm going to for lunch
[11:25] <seb128> bbiab
[11:25] <Sweet5hark1> seb128: k
[11:30] <Riddell> Sweet5hark1: nudge nudge :) https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1435764
[11:31] <Sweet5hark1> Riddell: hehe. annoying if one just joins a channel and misses a backlog, isnt it? ;)
[11:32] <Sweet5hark1> Riddell: bug just updated: its just about that patch for vivid, right?
[11:36] <Riddell> Sweet5hark1: there's a breeze icons tar too, commenting..
[11:42] <Riddell> Sweet5hark1: commented
[13:09] <desrt> rawr
[13:09] <seb128> hey desrt
[13:09] <larsu> morning desrt
[13:09] <desrt> good morning
[13:10]  * desrt faces his uphill battle for the day: freebsd file monitoring fixes
[13:12] <didrocks> morning desrt
[13:13] <desrt> bon matin
[13:14] <FJKong> willcooke: hey Will, I am back from NUDT this afternoon
[13:20] <willcooke> hey FJKong - hope you had a good trip.
[13:20] <willcooke> FJKong, My afternoon is fully loaded, can we try and catch up tomorrow?
[13:20] <mdeslaur> tedg: any update on your indicator-power silo?
[13:20] <FJKong> willcooke: no problem
[13:22] <tedg> mdeslaur, I realized I'm going to have to redo it because the testing changes are going to be too big for beta freeze.
[13:22] <willcooke> Sweet5hark1, congrats on Online docs! Very exciting
[13:22] <mdeslaur> tedg: ah :(
[13:22] <larsu> Sweet5hark1: what willcooke said
[13:26] <Sweet5hark1> willcooke: ahh, its just yet another platform ;P
[13:29] <willcooke> MOAR PLATFORMS
[13:30] <Sweet5hark1> willcooke: someone needs to bring back LibreOffice on Solaris with the Sun compiler. You volunteer?
[13:31]  * Sweet5hark1 remembers that was so much fun back in the days ...
[13:31]  * didrocks would prefer irix
[13:31] <willcooke> Sure why not.  What's a compiler?
[13:32] <tedg> willcooke, It's a computer program that teaches you new swear words
[13:32] <willcooke> tedg, oh!  Awesome. I need one of those.
[13:33] <Sweet5hark1> willcooke: a partner for shouting matches. Usually you throw four-letter words at it and it replies with page-long error messages -- at least for C++ ...
[13:33] <didrocks> well, if you use it, you will then lose at cards against humanity
[14:20] <desrt> man.  i missed the obscure-platforms mini-chat
[14:20] <desrt> that's like my favourite thing
[14:21] <desrt> did everyone know that minix is back in fashion?
[14:32] <seb128> cyphermox, hey there
[14:33] <cyphermox> seb128: hey!
[14:33] <cyphermox> good morning, how are you doing?
[14:34] <seb128> cyphermox, I'm good thanks, how are you?
[14:34] <seb128> cyphermox, do you know about bug #1421249 and who would be the right person to look at the issue?
[14:35] <seb128> cyphermox, basically if you boot touch with flight mode on, it's impossible to enable bluetooth, even after disabling flight mode
[14:37] <cyphermox> yeah
[14:37] <GunnarHj> happyaron, attente_, seb128: Should I go on with a l-s fix to handle bug #1435311?
[14:37] <cyphermox> the bluetooth touch upstart jobs need some more work
[14:38] <seb128> cyphermox, why is that related to upstart?
[14:38] <seb128> the flight mode is not an init thing, is it?
[14:39] <cyphermox> seb128: one of the issues is that in some cases you absolutely need to do some bluetooth firmware changes early on boot, perhaps even before urfkill starts
[14:39] <cyphermox> seb128: but you also need to ensure bluetooth is never started when flight mode is enabled, otherwise you're technically doing something illegal
[14:39] <cyphermox> there probably is some tweaking that needs to happen to satisfy both these conditions
[14:39] <seb128> hum, I see
[14:40] <seb128> do you think that's something you could look at? ;-)
[14:40] <cyphermox> since it's also dependent on whether the firmware changes need to happen before bluez is started or not
[14:40] <cyphermox> yeah, eventually :)
[14:40] <attente_> GunnarHj: i don't really understand why adding the Depends isn't enough. isn't fcitx already prioritized over ibus by im-config?
[14:41] <cyphermox> I think maybe we're safe from the "needs to happen before bluez starts" now, except maybe on nexus 7
[14:41] <attente_> like if the user has 'auto' in their .xinputrc, it should choose fcitx if fcitx-bin is installed, no?
[14:44] <GunnarHj> attente_: The problem is the timing. 1) l-s lists what should be installed, and since fcitx(-bin) is not there, nothing fcitx-* is included in the list. 2) Then the listed packages are installed, and only now fcitx-bin is pulled due to the depend. The other fcitx-* stuff is not installed, though, since it was never in the list to begin with.
[14:45] <GunnarHj> attente_: im-config only deals with already installed IM frameworks.
[14:47] <attente_> GunnarHj: are you talking about the "Keyboard input method system" combo?
[14:47] <GunnarHj> attente_: Well, the latter is not quite true with the latest changes... But the timing of the fcitx-bin install is still a problem.
[14:48] <attente_> if it's the combo it seems like it should be something fixed in l-s to refresh after an install
[14:48] <GunnarHj> attente_: At first hand I'm talking about which files are installed at the moment when you install a Chinese language.
[14:49] <attente_> ok, but a session restart is necessary to see the effects of the language change anyways, right?
[14:49] <attente_> what other fcitx-* stuff is needed besides fcitx-bin and fcitx-pinyin?
[14:50] <GunnarHj> attente_: If the user is changing the display language, so yes. But s/he may be installing a Chinese language only to get access to the IM stuff.
[14:50] <attente_> and that needs a session restart to take effect too, no?
[14:50] <GunnarHj> attente_: The whole approach with letting the display language determine the IM framework is rather fragile.
[14:51] <GunnarHj> attente_: Well, yes, in order for u-c-c to recognize the new stuff, you need to relogin.
[14:51] <attente_> right
[14:51] <GunnarHj> attente_: But you shouldn't need to open Language Support again.
[14:52] <GunnarHj> attente_: And redo it...
[14:52] <attente_> you mean re-open Language Support to switch from IBus to Fcitx?
[14:53] <attente_> i was saying if that's the problem, the combo widget in l-s should be refreshed after an install (if it doesn't it's a bug)
[14:53] <GunnarHj> attente_: To have the fcitx engines installed at first hand.
[14:53] <attente_> sorry if i'm misunderstanding, but i'm genuinely confused
[14:54] <GunnarHj> attente_: Please reread the bug description.
[14:55] <attente_> GunnarHj: i did. and i'm not sure why a language-pack-zh-hans(-base) Depends on fcitx-pinyin wouldn't work in this case
[14:56] <GunnarHj> attente_: Again, it is the timing. ^
[14:56] <attente_> GunnarHj: are we expecting it to install all chinese fcitx im engines?
[14:57] <GunnarHj> attente_: I'm assuming we want to install the Chinese IM engines which are listed in pkg_depends. And that will not happen with the language-pack-* depend you mentioned.
[14:59] <attente_> GunnarHj: ok, so this is some incongruity between the list that's displayed to the user and what is actually installed?
[15:00] <GunnarHj> attente_: The list is not shown to the user - it's created behind the scenes. And it does not include the fcitx IM engines unless fcitx (should be changed to fcitx-bin) is installed at that spot of time.
[15:02] <GunnarHj> attente_: That's why I suggest a l-s hack.
[15:03] <GunnarHj> attente_: If you start gnome-language-selector from terminal, and install a language, you'll see the list, though.
[15:07] <GunnarHj> attente_: I just thought of another possibility... Maybe we should simply remove the fcitx condition in the Chinese entries in pkg_depends. Then your depend idea would probably work.
[15:08] <GunnarHj> attente_: OTOH I'm not sure how you edit the language-packs. I think they are created automatically via langpack-o-matic or something...
[15:09] <attente_> GunnarHj: ok, so it sounds like a l-s hack is probably unavoidable then...
[15:10] <GunnarHj> attente_: Ok, I'll take a look. It's probably a pretty easy thing. I'll let you know if I need help. See you later (maybe tomorrow).
[15:11] <attente_> GunnarHj: ok, thanks
[15:13] <GunnarHj> attente_: Btw, the IM combo you mentioned is a separate story. Currently ~/.xinputrc is created automatically the first time a user opens gnome-language-selector, so a later install of a Chinese language won't automatically switch the IM framework to fcitx, but the user needs to do it manually.
[15:15] <GunnarHj> attente_: Personally I think we should keep it that way. It makes not sense at all to me that the IM framework is automatically changed only because the user changes display language.
[15:19] <attente_> GunnarHj: yeah, i'm not sure. if they never explicitly set it (i.e. auto), is it safe to assume they'd be ok with switching...
[15:23] <GunnarHj> attente_: I don't think it would be safe. Let's take the simplest example: A Chinese install. The user starts using fcitix IM, and then for some reason changes the display language to English (without touching the combo). It's reasonable to assume that s/he wants to keep using fcitix for IM things even if the display language is English.
[15:29] <ngochai> Hi guys, my Xorg server crashes like this http://pastebin.com/qXATtm4s any idea?
[15:36] <seb128> larsu, are you still looking at this nautilus zooming issue? I've an upload I want to do, wondering if I should wait on an eventual fix or just go with what I have and do another one later if needed
[15:37] <larsu> seb128: I didn't get to it yet sorry. Please go with what you have for now
[15:38] <seb128> larsu, k, thanks
[16:13] <seb128> larsu, opened https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1436428 and added to your queue, hope it's ok ;-)
[16:13] <seb128> not sure if that's a theme issue
[16:15]  * larsu nods silently
[16:29] <greyback> seb128: hey, I'm looking into UI scaling work that was done for unity - where you could scale up/down UIs on each screen
[16:30] <greyback> there's a dconf setting: con.canonical.user-interface.scale-factor being used
[16:30] <seb128> greyback, hey
[16:30] <greyback> I'm trying to find the gtk code that reads and monitors that value, any idea where it is?
[16:30] <seb128> there is none
[16:31] <seb128> gtk knows only of one scale factor and it's in org.gnome.desktop.interface scaling-factor
[16:31] <seb128> which is read by gnome/unity-settings-daemon which set the corresponding xsettings
[16:31] <seb128> that's not a by monitor value though
[16:32] <greyback> so I've 2 monitors set up here, one with different scale to the other. gedit (mostly) rescales when I move it from one monitor to the other
[16:34] <seb128> it does?
[16:34] <greyback> yeah
[16:34] <seb128> what change?
[16:35] <greyback> if I manually edit com.canonical.user-interface.scale-factor, gedit rescales
[16:35] <seb128> right
[16:35] <seb128> but that's not by monitor
[16:35] <greyback> it is
[16:35] <seb128> it should apply the same scale factor to gtk independently of the monitor
[16:35] <seb128> well the key is
[16:35] <seb128> and unity has different scaling by monitor
[16:35] <seb128> which applies to decoration, launcher, etc
[16:36] <seb128> it also tweak the gtk scaling behind the scene
[16:36] <seb128> but I though that the gtk factor was not by monitor...
[16:36] <seb128> I might be wrong though
[16:36] <seb128> larsu, Trevinho^ ?
[16:36] <greyback> lemme test more, perhaps I'm not interpretting "scaling" correctly
[16:37] <greyback> ah, font sizes are being changed
[16:38] <greyback> it's not scaling anything
[16:38] <greyback> for anyone playing along at home, I have a typo above, it is: "com.ubuntu.user-interface.scale-factor"
[16:40] <seb128> greyback, if you want to see scaling do "gsettings set  com.canonical.user-interface.scale-factor 2"
[16:40] <seb128> greyback, or use e.g GDK_SCALE=2 gedit
[16:42] <greyback> seb128: yeah I see it (for a microsecond, before something reverts it back to 1)
[16:42] <greyback> seb128: thanks, I see what's happening now
[16:42] <seb128> greyback, oh, right, unity tries to be smart, doing GDK_SCALE=... gedit
[16:43] <greyback> seb128: yeah that's nice
[17:08] <larsu> seb128: no clue, that's a Trevinho/bregma question
[17:08] <seb128> larsu, the question was whether the gtk scaling factor was per monitor, I though it was not
[17:10] <larsu> seb128: it is
[17:10] <larsu> at least according to the API
[17:10] <seb128> larsu, how does that work with the xsettings/gsettings key?
[17:10] <larsu> not sure if it dynamically changes it
[17:10] <larsu> dunno
[17:11] <bregma> it used to be one single value system-wide
[17:11] <seb128> larsu, I only know of  com.canonical.user-interface.scale-factor
[17:11] <seb128> which is one number
[17:11] <seb128> int
[17:11] <bregma> there's also the text-scale-factor which is independent
[17:11] <seb128> but also one value?
[17:11] <larsu> there's gdk_screen_get_monitor_scale_factor()
[17:12] <larsu> not sure if that ever returns different values though
[17:13] <larsu> ya, it always returns the same value on x
[17:20] <seb128> larsu, thanks
[17:38] <happyaron> attente_: see my reply at bug #1435311
[17:53] <Trevinho> seb128: yeah, what you said to greyback is right
[17:53] <Trevinho> greyback: the thing is that gtk doesn't support real scaling factor values, but only integers
[17:54] <Trevinho> greyback: so... to workaround that if you set something such as 1.8, then we use the font-scaling factor + the ui scaling factor to get the proper value
[17:55] <Trevinho> and, the gtk scaling factor is actually global... I mean, although every screen can have a difrenent one, the apps doesn't update automatically afaik
[18:19]  * willcooke -> EOD. g'night all
[18:35] <tkamppeter> Has someone already tried Vivid on a virtual machine (Utopic as host). For me it does not work at all. It stops booting after the first update.
[18:36] <sarnold> tkamppeter: are you by chance using ext3?
[18:36] <tkamppeter> ext3 as the hosts file system?
[18:36] <sarnold> tkamppeter: yeah
[18:37] <tkamppeter> No, I am using ext4
[18:37] <sarnold> ahh, looks like the bug I'm thinking of can also happen if your ext4 fs doesn't use extents, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1292234
[18:39] <tkamppeter> sarnold, what do I have to do to fix it?
[18:39] <sarnold> tkamppeter: if this specific bug is the one you hit, you can either turn on extents or use saucy's qemu/kvm/etc
[18:40] <tkamppeter> sarnold, and how do I turn on extents?
[18:41] <sarnold> tkamppeter: tune2fs can do that
[18:46] <tkamppeter> sarnold, I did sudo tune2fs -O extent /dev/sda1 now and after rebooting the host I can boot Vivid in the VM again. Thank you very much. extents should be made default.
[19:07] <qengho> Does anyone else use internet connections who catch bad hostnames, in order to redirect you to their own web servers?
[19:08] <qengho> (In tech jibberjabber, id est, NXDOMAIN hijacking.)
[19:09] <maxb> Fortunately my ISP at least allows that stupidity to be turned off
[19:48] <qengho> Ah well. I don't like nxdomain hijacking. I'm technical enough to fix it, but our users aren't. I just made a networkmanager/ifupdown plugin to fix it automatically. I'm hoping for feedback.
[19:50] <happyaron> qengho: I see nxdomain hijacking all the time
[19:50] <sarnold> qengho: nice
[19:59] <qengho> happyaron: dui4buqi3, install "dns-veracity" from ppa:cmiller/ppa ?  This is the only file installed:  http://bazaar.launchpad.net/~cmiller/+junk/dns-veracity/view/head:/etc-network-ifup-script
[20:00] <happyaron> looks handy
[21:41] <sarnold> qengho: if someone returns ipv6 addrs instead of ipv4 headers, this script appears to ignore them
[21:45] <qengho> sarnold: that's right. I only ask for A records, and I filter anything not \d and . . I could test for AAAA and : later, I guess.
[21:46] <sarnold> qengho: probably not a huge deal today :) but perhaps some mobile operator has ipv6-only or something similar..
[21:54] <qengho> sarnold: $ host -t aaaa ipv6.test-ipv6.com.    #-> ipv6.test-ipv6.com has no AAAA record    # any idea the problem?
[21:56] <qengho> -t ANY  works.
[21:56] <sarnold> qengho: do your resolvers used for the query ignore ipv6 responses? I got back an AAAA from that..
[21:57] <qengho> Hrm. Could be.
[21:57] <sarnold> qengho: I can't recall if there's a handy switch for the resolver interface to ignore AAAA responses.. I could have sworn I've seen one somewhere but I didn't spot it in the manpages I thuoght to check
[23:07] <qengho> sarnold: http://bazaar.launchpad.net/~cmiller/+junk/dns-veracity/view/head:/etc-network-ifup-script  ???
[23:28] <sarnold> qengho: looks great