[00:11] <qengho> Any idea what could be causing kworker and ksoftirqd "processes" to use 28%, 29%, 15%, 14% CPU on my vivid machine?  Nothing unusual in dmesg.
[00:12] <qengho> ah, and khubd. 14%.
[00:14] <qengho> Loads vary. ps |top -nsomething:  http://paste.ubuntu.com/10588375/
[00:15] <qengho> |head , of course.
[04:31] <pitti> Good morning
[06:13] <didrocks> good morning
[06:21] <pitti> bonjour didrocks, comment vas-tu?
[06:27] <didrocks> ça va, et toi pitti ? Bientôt les vacances ;)
[06:28] <pitti> en effet !
[06:28] <didrocks> profitez-en bien !
[06:30] <didrocks> pitti: on the upstream ML, I disagree with Lennart on downgrading and exit 0 if we can't unmount(), I feel that the unit should fail if we failed to unmount and so, writing persistent commit-id to disk instead of just appeared as if everything worked fine. especially as our other solution is giving us a 100% accuracy method to know if it should work or not (and even, results in the exec not being
[06:30] <didrocks> started at all)
[06:30] <pitti> didrocks: yes, I agree
[07:36] <didrocks> pitti: I hereby declare whoopsie conffile dead \o/
[07:36] <pitti> rockin'!
[07:36] <didrocks> I move the optional report_metrics to /etc/whoopsie which isn't a conffile
[07:36] <pitti> control-center now directly update-rc.d enable|disable it?
[07:37] <didrocks> and read from that
[07:37] <pitti> ah
[07:37] <didrocks> for "report crashes", yeah
[07:37] <didrocks> it's using update-rc.d + invoke-rc.d
[07:37] <didrocks> and detects if we are under upstart or systemd to show the right status in the capplet
[07:37]  * pitti just fixed CD ejection for the third time or so, and hopes we can finally put a lid on that
[07:37] <pitti> didrocks: yay!
[07:37] <didrocks> (remember, there are 2 values: report_crashes -> job enablement and report_metrics -> another value)
[07:38] <didrocks> no more [General]
[07:38] <pitti> right
[07:38] <didrocks> pitti: do you know what regressed again CD ejection?
[07:39] <didrocks> pitti: TBH, I needed to "look" for a neighboor some CD stuck in the tray of a Mac book. We are not the only one to have issues with the "eject" command
[07:39]  * didrocks spent one hour to get it out, and it was really random, and of course, no hole to force mechanical ejection
[07:40] <pitti> didrocks: oh, it didn't regress in Ubuntu yet, just in trunk
[07:40] <didrocks> ah :(, and I guess a test on this without legos isn't easy (or you do have an awesome mock?)
[07:41] <pitti> legos?? :-)
[07:41] <pitti> didrocks: yes, I do have an awesome mock, it's called QEMU :)
[07:41] <pitti> you can simulate pressing the eject drive button there
[07:42] <didrocks> oh nice, so you can pilot that from outside
[07:42] <pitti> I tinkered around a bit with something like echo -e 'change\nDISK_EJECT_REQUEST=1' | sudo tee /sys/block/sr0/uevent, but that doesn't work
[07:42] <pitti> i. e. I haven't figured out how to synthesize uevents with kernel properties, but QEMU is good enough (just not automatable in an autopkgtest)
[07:43] <didrocks> oh, you need to pass a verb in uevents first? interesting
[07:43] <didrocks> yeah
[07:48] <pitti> didrocks: yes, with just "add" or "change" it works fine (that's how it's designed)
[07:49] <pitti> didrocks: but you can't add additional properties
[07:53] <pitti> didrocks: btw, on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=systemd-boot I'm going to work on bug 1431200 next, that's quite a bummer too
[07:54] <pitti> didrocks: if you come across anything which breaks systemd, can you please tag it systemd-boot? and perhaps have a look at that next week?
[07:54] <didrocks> pitti: sure, will look at the tag
[07:54] <didrocks> I should have whoopsie added to it, but too late now ;)
[07:54]  * didrocks looks at final diffs for whoopsie & whoopsie-preferences
[07:56] <willcooke> morning!  Anyone got the new Chromium installed?  I think the hidpi fixes have caused a regression.  If I right click in the window the menu opens in the wrong place
[07:58] <didrocks> hey willcooke, which version of chrome? (not sure to have upgraded)
[07:58] <willcooke> Version 41.0.2272.76 Ubuntu 14.04 (64-bit)
[07:59] <didrocks> willcooke: ok, let me upgrade
[08:00] <didrocks> up early btw :)
[08:01] <willcooke> yeah :(
[08:01] <willcooke> children
[08:02] <willcooke> hrm - fonts seem "blurred" as well - like the page is set to a zoom factor != 100%
[08:02] <willcooke> (but it is set to 100%)
[08:03] <didrocks> willcooke: interesting, I don't have that in latest chrome fyi, still upgrading for chromium
[08:03] <willcooke> pretty sure this is related to hidpi fixed
[08:04] <willcooke> hrm, drop downs seem broken as well
[08:04] <willcooke> lots of bugs
[08:06] <willcooke> no clicky finger mouse icon
[08:06] <willcooke> when hovering on links
[08:06] <didrocks> either your machine in on a pretty bad state or chromium is :)
[08:06] <didrocks> you are on a non dpi machine, right (just to ensure I'll test the same thing?)
[08:06] <willcooke> yeah, normal dpi
[08:06] <didrocks> sorry, non hdpi*
[08:07] <didrocks> ;)
[08:07] <didrocks> let's see (compiling and upgrading at the same time :p)
[08:07] <willcooke> :)
[08:07] <willcooke> Sigh - it's too hard to find the right place to log bugs against Chromium in LP
[08:08] <didrocks> chromium-browser
[08:08] <didrocks> so obvious though :p
[08:08] <willcooke> thx didrocks
[08:08] <larsu> morning all!
[08:08] <didrocks> willcooke: yeah, it's like the git case in the past, chromium is a game, and so "first wins" instead of "more popular"
[08:08] <didrocks> good morning larsu
[08:08] <willcooke> hey larsu
[08:10] <willcooke> didrocks,  https://www.youtube.com/watch?v=WmfvC0g2y7o&feature=youtu.be
[08:10] <didrocks> why didn't I upgrade yesterday… webkit, qt… a lot of friends wanting to upgrade:)
[08:11] <didrocks> willcooke: there is one bug in your video: the hamburger menu is at the right place if the window isn't maximized
[08:17] <willcooke> And the award for vaguest bug report of 2015 goes to....
[08:17] <willcooke> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1431720
[08:18] <didrocks> willcooke: can't reproduce here :/
[08:18] <willcooke> hrm
[08:18] <didrocks> 41.0.2272.76 Ubuntu 15.04 (64-bit)
[08:18] <didrocks> I'm on vivid though
[08:19] <didrocks> can be LTS + backported chromium
[08:37] <didrocks> I would really have prefered this https://plus.google.com/+google/posts/c2VSg3BMWk9 to 7h of (night) bus…
[08:38] <didrocks> but we were 203 days too early (they had a counter in the train station to announce the shinkansen arrival)
[08:47] <willcooke> sweet!
[09:03] <Laney> hello!
[09:03] <didrocks> hey Laney!
[09:04] <Laney> happy friday!
[09:04] <didrocks> happy friday -1h as well :)
[09:05] <larsu> morning Laney!
[09:06] <Laney> heeeeeeey larsu
[09:08] <seb128> good morning desktopers
[09:08] <seb128> happy friday
[09:08] <seb128> hey didrocks Laney larsu
[09:09] <didrocks> re seb128
[09:13] <ogra_> pitti, Laney, FYI, desktop-next still doesnt build
[09:13] <pitti> bonjour seb128
[09:14] <pitti> ogra_: what was that URL again?
[09:14] <Laney> oh noes
[09:14] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-desktop-next
[09:16] <pitti> Package: ubuntu-touch-customization-hooks
[09:16] <pitti> Depends: upstart
[09:16] <pitti> Task: ubuntu-touch-core, ubuntu-desktop-next, ubuntu-touch
[09:16] <pitti> that would be one reason?
[09:16] <pitti> I can't see anything else
[09:17] <pitti> do we actually need that on desktop-touch?
[09:17] <pitti> err, desktop-next?
[09:17] <pitti> ogra_, Laney ^
[09:17] <Laney> pitti: upstart | upstart | ubuntu-touch-customization-hooks | James Hunt<EMAIL_ADDRESS>| 76148 | 409
[09:17] <Laney> that is it
[09:18] <Laney> from http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.vivid/touch-core
[09:18] <pitti> so if we need it on desktop-next, it needs to get a unit and drop the upstart dep; if we don'tt need it, we'll move it in the seed?
[09:18] <Laney> seems fair
[09:23] <ogra_> pitti, thats a massive amount of changes i fear
[09:24] <pitti> ogra_: we have touch customization hooks for desktop-next?
[09:24] <ogra_> there is logic to actually run the customization bits on system and user level that is very upstart specific
[09:24] <Laney> It's about putting stuff in /custom/
[09:24] <Laney> which doesn't even exist in next I don't think
[09:24] <ogra_> click apps live in the custom tarball
[09:25] <ogra_> i assume at some point we want to use the same on desktop
[09:25] <ogra_> oh, and scopes
[09:26] <ogra_> not sure if you could unseed it without harming functionallity
[09:26] <pitti> ./usr/share/upstart/sessions/custom-env.conf would obviously continue to work (that's upstart-bin)
[09:27] <pitti> ./etc/init/custom-apparmor-cache.conf and ./etc/init/custom-dconf-update.conf seem fairly straightforward to port
[09:28] <pitti> that logic should be put into a script in /usr/share, then the upstart job and the systemd units could just call it
[09:28] <pitti> ah, "start on starting click-system-hooks" would not work
[09:41] <Laney> happyaron: thx for fcitx fix
[09:42] <Laney> how's it started now? by im-config?
[09:42] <larsu> Laney: 75% of those words end on x.
[09:42] <seb128> :-)
[09:42] <larsu> I think you can do better…
[09:42] <Laney> I BELIEVE
[09:43] <larsu> I KNOW
[09:43] <happyaron> Laney: there's an xdg autostart, it's expected to quit when env variable not set to it, but apparently it didn't, so I removed that xdg autostart
[09:43] <Laney> yes the diff is quite clear
[09:44] <Laney> I want to know how it's started for users who actually do want it now
[09:45] <happyaron> don't understand your question, for which?
[09:45] <Laney> if you removed the xdg autostart file
[09:46] <Laney> then what other way is it started?
[09:46] <happyaron> im-config will start it when needed
[09:46] <Laney> ok
[09:55] <Laney> oh man
[09:55] <Laney> alt-space, x doesn't work on shell
[09:57] <larsu> Laney: because of the new window menu?
[09:57] <larsu> s/new/non-gtk/
[09:58] <Laney> what's that?
[09:58] <larsu> the menu you see when you hit alt+space
[09:58] <Laney> looks like a popover
[09:59] <larsu> yeah but I think it's drawn by st now
[09:59] <Laney> well, whatever it is, it doesn't have an x accelerator
[09:59] <larsu> or mnemonics at all…
[10:18] <didrocks> happyaron: can you get the desktop team subscribed to extra-cmake-modules bugs please? It seems we have a (very) recent discussions asking to have Canonical people being subcribe for a package to get in Main
[10:20] <happyaron> didrocks: maybe we need to ask seb128
[10:20] <happyaron> seb128: ^^ can you subscribe desktop-bugs to extra-cmake-modules?
[10:21] <seb128> happyaron, didrocks, done
[10:21] <didrocks> thanks guys
[10:21] <happyaron> thanks
[10:28]  * Laney downloads a fedora iso :cool:
[10:29] <seb128> Laney, why do you need fedora for jhbuild?
[10:30] <Laney> got a strange patch review
[10:30] <seb128> strange like?
[10:30] <Laney> says that it doesn't work properly
[10:31] <Laney> the cheek of it!
[10:31] <Laney> (that's why I'm in shell atm)
[10:31] <Laney> (and it does)
[10:31] <seb128> what patch is that?
[10:31] <Laney> for headerbars
[10:34] <seb128> of course, what else :p
[10:34] <Laney> <insert daily headerbar discussion here>
[10:35] <Laney> now we can move on with our lives :p
[10:35] <larsu> HEADERBARS
[10:35] <Laney> i noticed that we didn't get a promoted (pending/ to current/) desktop iso
[10:35]  * larsu runs out
[10:35] <Laney> since march 6th
[10:35] <Laney> who wants to look ;-)
[10:40] <darkxst> didrocks, seb128, Laney, shouldnt the whole MIR thing be run via the TB, and not just Steve's say so? and yes I know he is part of that
[10:41] <didrocks> darkxst: we will discuss it in the MIR team first (I'll ping mterry this afternoon)
[10:41] <Laney> ya I think it's a MIR team decision in the first instance
[10:41] <didrocks> darkxst: however, I think the tracker changes were needed
[10:42] <didrocks> darkxst: doesn't change anything for you, and we support more libs in addition to your team
[10:42] <didrocks> so it's a win for you guys on that one
[10:43] <darkxst> didrocks, sure, that one is
[10:43] <didrocks> darkxst: I wouldn't touch grilo-plugins until we discuss though
[10:44] <didrocks> even if it's clear, the desktop team will support it due to new totem I guess
[10:44] <didrocks> but let's use it as an example
[10:44] <didrocks> before we go again on the same case
[10:44] <darkxst> didrocks, didrocks did you demote -extra?
[10:45] <darkxst> I did see a ping about it
[10:45] <didrocks> darkxst: I guess you mean -extract, right?
[10:45] <didrocks> darkxst: if so, as stated on the bug, yeah
[10:45] <Laney> what tracker changes?
[10:45] <didrocks> Laney: https://bugs.launchpad.net/ubuntu-gnome/+bug/1313996/comments/17
[10:46] <darkxst> didrocks, grilo-plugins-extra is still in main
[10:46] <didrocks> darkxst: ah, no, only changed tracker
[10:46] <didrocks> darkxst: let's wait on the discussion to be settled
[10:47] <darkxst> well that was the whole idea of the split, only grilo-plugins-base needs to be in main
[10:48] <Laney> Personally I find the grilo case to be clearer cut than the tracker one
[10:48] <didrocks> darkxst: I wasn't aware that grilo-plugins has been promoted without the bug being closed?
[10:48]  * didrocks checks it's not me at least first, but I don't generally do that
[10:49] <didrocks> and paste the output on the bug
[10:49]  * Laney stabs apparmor
[10:49] <didrocks> (but LP can timeouts)
[10:49] <didrocks> darkxst: do you know who promoted it?
[10:50] <darkxst> didrocks, no idea
[10:56] <darkxst> Laney, well that was why we split grilo-plugins into base/extra
[10:57] <Laney> I understand why that was done
[10:59] <didrocks> darkxst: at least, this discussion triggered that there is a process flow: someone promoted grilo-plugins without looking at the comment, closing the bug and put -extra in it
[11:04] <darkxst> didrocks, yes, agree on that, still no idea how it got promoted though
[11:08] <didrocks> we only have the date… :/
[11:09] <darkxst> didrocks, which would have been around when totem was uploaded I guess
[11:10] <didrocks> yep
[11:24] <Laney> happyaron: you didn't add a maintscript to remove the conffile from fcitx
[11:24] <Laney> so it's still there on upgrade
[11:24] <Laney> the rise of the undead indicator
[11:24] <happyaron> ah... ok
[11:38]  * Laney had to hack anaconda to get it to complete the installation
[11:38]  * Laney @fedora.org
[11:38] <Chipaca> is anybody looking for cases where systemd doesn't want to boot the system?
[11:39] <Chipaca> or should i reboot and get on with stuff?
[11:41] <Chipaca> pitti: ^ you?
[11:42] <pitti> Chipaca: that's not much to go on -- can you please file a bug with the details, logs, etc?
[11:42] <pitti> Chipaca: and yes, I'm very interested in these
[11:42] <Laney> oh for gods sake, another crash
[11:42] <Chipaca> pitti: that means rebooting; i'm asking like i'm asking because the thing is happening right now :)
[11:42]  * Laney stabs fedora
[11:42]  * Laney gets a release instead of rawhide
[11:42]  * desrt slowly steps back from Laney
[11:43] <pitti> Laney: I tried to install rawhide two weeks ago, it was impossible
[11:43] <pitti> the very first thing in the installer is broken, and rawhide upgrade took like 4 hours and then crashed
[11:43] <pitti> I also went with F21 and upgraded some pacakges manually
[11:43] <Laney> yes, I hacked around the first crash
[11:43] <pitti> Chipaca: can you do/see anything on the machine?
[11:43] <Laney> and now it's complaining about not being able to find resolv.conf
[11:43] <Laney> wonder why that could be ^o)
[11:43] <pitti> Chipaca: you mean it sometimes boots and sometimes not?
[11:43] <Chipaca> pitti: yes
[11:44] <Chipaca> pitti: sometimes it boots, sometime it gest stuck like this
[11:44] <pitti> Chipaca: ok, so please define "like this"
[11:44]  * Chipaca waits for photo to upload
[11:45] <Chipaca> pitti: http://i.imgur.com/LBb17AV.jpg
[11:46] <pitti> Chipaca: ok, you definitively want to uninstall powerd, but that should be unrelated
[11:46]  * Chipaca wonders what dependency got that one installed
[11:46] <Chipaca> rebooting, then
[11:47] <pitti> Chipaca: hm, so /usr/sbin/update-binfmts --enable seems to hang, I've never seen that
[11:47] <Chipaca> pitti: network manager and modem manager took their sweet time too
[11:47] <pitti> and modemmanager too, these are fairly unrelated; I wonder if somehting else failed before
[11:48] <pitti> Chipaca: yeah; I suggest booting with a debug shell (/usr/share/doc/systemd/README.Debian), and grabbing "journalctl -b > journal.txt", and attaching that to a bug
[11:48] <Chipaca> you can't even c-a-d out of the boot process, that's weird
[11:49] <pitti> Chipaca: such random failures are often caused by dependency loops recently; the journal should tell me what's going on (if not, we'll need the same with "debug")
[11:49] <pitti> Chipaca: you can try pressing it > 7 times very fast
[11:49] <pitti> otherwise, SysRq FTW?
[12:02] <Chipaca> pitti: now booted five times without repro'ing it :(
[12:02] <Chipaca> every boot takes a couple of minutes i'm afraid
[12:08] <pitti> Chipaca: uh, does it take that long? what's blocking there?
[12:09] <pitti> Chipaca: can you give me journalctl from a successful boot? if it's a cycle, it should appear there
[12:09] <pitti> (just to check if anything else looks strange)
[12:09] <Chipaca> pitti: i've got to edit grub, then enter my passphrase, and smartmond asks my ssd to do something it can't so that times out
[12:10] <Chipaca> pitti: and i'm in the middle of debugging fglrx not playing ball, so everything is broken in different, orthogonal ways
[12:12] <Chipaca> pitti: what's the bug against?
[12:12] <pitti> Chipaca: I don't know yet :) you can just pastebin the successful journal
[12:12] <pitti> Chipaca: but in general, you can start with systemd, and I'll reassign if appropriate
[12:12] <pitti> that's at least a sure way to get it to my attention
[12:13] <attente_> seb128: hi, can you take a look at https://code.launchpad.net/~attente/unity-settings-daemon/1430971/+merge/252830 and https://code.launchpad.net/~attente/unity-control-center/1430971/+merge/252831? i removed the recommends on fcitx-data so it shouldn't pull in fcitx-bin on dist-upgrade
[12:13] <Chipaca> pitti: http://pastebin.ubuntu.com/10590521/
[12:14] <pitti> Chipaca: ok, nothing unexpected there (no cyclic dependencies or so)
[12:14] <Chipaca> pitti: boo :)
[12:16] <willcooke> Laney, design have added updated wallpaper to the bug.  There is an 8 bit version, but I think it looks less good - there is some banding in the bottom right corner which I dont see as much on the 24 bit version.  Could you try and crunch the 24bit version?
[12:23] <Laney> willcooke: ya I saw it, lemme see
[12:24] <willcooke> Laney, trying a crush -reduce on it....
[12:24] <willcooke> Laney, not much to be gained I think
[12:24] <Laney> 4.8 MB ...
[12:24] <willcooke> 4.4 with application of the crushinator
[12:25] <willcooke> 9% reduction
[12:25] <willcooke> obvs
[12:25] <desrt> Laney does compression now?
[12:25] <willcooke> desrt, he does it free hand with MS paint
[12:25] <willcooke> alexabreu,
[12:26] <willcooke> oops sorry alexabreu
[12:34] <alexabreu> :)
[12:41] <ChrisTownsend> mlankhorst: Any chance you can update your Xmir PPA?  xorg-server package in vivid archive is newer than your PPA, so no more Xmir.
[12:48] <seb128> attente_, hey, thanks, I'm going to land those
[12:58] <attente_> seb128: thanks
[13:03] <Laney> willcooke: yeah this is madness, I can't get it small enough
[13:11] <willcooke> qengho, morning!  Upgraded Chrm last night.  This morning:  https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1431720
[13:25]  * mterry sees didrocks cleaning up quickly bugs, plays Taps
[13:25] <happyaron> attente_: what's next for the FFe?
[13:27] <qengho> willcooke: Weird.  Normal 1:1 is "8".
[13:33] <qengho> willcooke: $ xrdb -query |grep dpi
[13:33] <willcooke> Xft.dpi:	96
[13:34] <qengho> Also normal.
[13:34]  * qengho thinks.
[13:34] <willcooke> qengho, I'm on a hangout, but I'll try rebooting in a bit
[13:35] <qengho> willcooke: Eh, well, I *hope* rebooting doesn't fix it, because that would mysterious and I hate mysterious.
[13:36] <willcooke> :)
[13:39] <willcooke> qengho, thinking about it some more - everything else is normal, gtk apps, xapps etc - so does seem to be only Crm
[13:42] <mdeslaur> larsu: did you have a headerbar patch for recent gedit somewhere?
[13:43] <jdstrand> Laney: hey, you seem stabby this morning :) was there something you needed wrt apparmor?
[13:44] <larsu> mdeslaur: can't find it right now :(
[13:45] <larsu> mdeslaur: I don't think I did it properly yet. Just a quick hack to see what it looks like
[13:45] <larsu> and gave up after we couldn't decide on a toolbar layout
[13:46] <mdeslaur> larsu: after fixing a bajillion deprecated things in the old gedit, I now hit GtkActionEntry crap, and well, now I'm thinking adding a few extra buttons to the new gedit would probably be simpler :P
[13:48] <larsu> mdeslaur: haha might well be
[13:49] <larsu> but if you recreate the old toolbar, how do decide when to show it?
[13:49] <larsu> based on shellshowsmenubar? That would be quite ugly
[13:49] <mdeslaur> larsu: show it in unity only, leave the default layout for the other desktops, like we do now
[13:49] <mdeslaur> or just add the extra buttons in unity
[13:50] <mdeslaur> and make the header use that setting
[13:50] <seb128> getenv XDG_CURRENT_DESKTOP?
[13:50] <larsu> ah, tie it to showing the headerbar
[13:50] <larsu> that will be some interesting logic, because users can also decide not to show the toolbar
[13:50]  * larsu does that
[13:51] <qengho> "interesting logic"
[13:51] <qengho> Scary words.
[13:51] <larsu> qengho: it's not hard. I'm just making sure mdeslaur thinks about all the cases when he implements it ;)
[13:51] <larsu> s/all the cases/my case/
[13:52] <mdeslaur> larsu: hehe
[13:52] <mdeslaur> larsu: I'll do the extra buttons if you give me a headerbar patch
[13:54] <larsu> mdeslaur: you want to recreate the same layout?
[13:54] <larsu> with colored icons?
[13:54] <larsu> open recent was changed quite a bit
[13:56] <mdeslaur> larsu: I'm not sure...so the issue was it was ugly with only a couple of buttons on the left of the toolbar?
[13:57] <larsu> mdeslaur: there's no toolbar anymore
[13:57] <larsu> I tried making the current header bar a toolbar, but that failed...
[13:57] <mdeslaur> well, once you drop the headerbar buttons into the toolbar
[13:57] <mdeslaur> failed?
[13:57] <larsu> ya, it's ugly
[13:58] <larsu> you can't just hide the headerbar and show a new toolbar, because its actually two headerbars (one for the sidebar(
[13:59] <larsu> if you remove the headerbar, you can't switch between sidebars anymore
[14:00] <mdeslaur> larsu: oh, hrm
[14:00] <mdeslaur> larsu: this was your last screenshot I believe: http://i.imgur.com/XGAud8K.png
[14:02] <larsu> mdeslaur: looks about right. That toolbar is a headerbar (which has differntly styled buttons)
[14:02] <larsu> we could remove the headerbar class on there I guess
[14:02] <mdeslaur> yeah, I'd just reorder them and add a couple more
[14:02] <larsu> but keep them symbolic?
[14:02] <mdeslaur> sure
[14:03] <mdeslaur> just so it doesn't look...empty
[14:03] <larsu> this is not how we should design things...
[14:04] <mdeslaur> ok, so forget about it then, I'll live with the old one
[14:07] <larsu> mdeslaur: I want the update as much as you do, but let's not change ui under our user's noses without thinking about it a bit
[14:09] <mdeslaur> I think keeping the modern headerbar look in the toolbar, but adding a few more buttons so it's not as empty and resembles the toolbar in the old version sounded reasonable
[14:11] <mdeslaur> larsu: what do you propose doing?
[14:11] <larsu> mdeslaur: I don't have a solution. This is why we're talking about header bars every day...
[14:12] <larsu> mdeslaur: we did switch some apps in the way you mentioned, but all of them have completely new button layouts
[14:13] <mdeslaur> so leave the button layout as is then, I don't care
[14:14] <larsu> mdeslaur: seb128 doesn't like that...
[14:14] <seb128> like what?
[14:15] <larsu> seb128: using gedit's new headerbar as a toolbar
[14:15] <larsu> (as-is)
[14:16] <seb128> did I say that?
[14:16] <larsu> yes?!
[14:17] <Laney> jdstrand: bug #1393842
[14:17] <seb128> larsu, I would need to look at it again
[14:17] <Laney> worked around it by saying the VM was ubuntu :)
[14:17] <seb128> larsu, google image shows things like https://en.opensuse.org/images/a/a4/OS1320_SPG_Gedit-menu2.png
[14:17] <Laney> I think it might actually not be an apparmor bug though
[14:17] <seb128> larsu, I think that would be fine, my concern was about not having access to easy/common actions like open or save
[14:18] <larsu> seb128: right. http://i.imgur.com/XGAud8K.png
[14:18] <seb128> larsu, I think your screenshot didn't have those?
[14:18] <seb128> or was it print?
[14:18] <seb128> but print is not that common...
[14:18] <larsu> open/save/new are on there
[14:18] <larsu> nothing else
[14:18] <mdeslaur> the hamburger menu is missing
[14:19] <larsu> mdeslaur: because we don't need it woith a traditional menubar
[14:19] <larsu> mdeslaur: https://bugzilla.gnome.org/show_bug.cgi?id=741904
[14:21] <mdeslaur> larsu: ah, that makes sense
[14:21] <seb128> larsu, the discussion was on http://irclogs.ubuntu.com/2015/01/26/%23ubuntu-desktop.html#t15:43
[14:21] <seb128> larsu, so yeah, our discussion by then sidetracked on "they have no toolbar on macOS"
[14:21] <seb128> which I didn't find acceptable since you don't have easy access to open/save/...
[14:22] <seb128> I agree the screenshot doesn't look great
[14:22] <seb128> but I would opposite landing new gedit like that
[14:22] <seb128> wouldn't*
[14:22] <mdeslaur> seb128: without the toolbar, or with the sparse toolbar?
[14:23] <seb128> no toolbar = no go
[14:23] <seb128> as said you don't even have access to open/save/etc without having to the menus which is inefficient and not discoverable
[14:23] <seb128> the sparse toolbar doesn't look great but works
[14:23] <seb128> and if that allows us to update to a modern/supported gedit...
[14:23] <jdstrand> Laney: I commented in the bug. there is also another workaround you can apply (see comment #2)
[14:24] <larsu> seb128: the reason we're doing it is because of deprecation warnings... not sure that should be the driver
[14:24] <seb128> larsu, indeed not, I wouldn't update only for that
[14:25] <seb128> I didn't check how many issues have been fixed in the new version and how many new features/nicety added
[14:25] <Laney> jdstrand: thanks for looking
[14:25] <seb128> we should decided based on that
[14:25] <Laney> I only found the bug after the workaround
[14:25] <seb128> decide
[14:25] <larsu> seb128: agreed
[14:25] <mdeslaur> is gedit one of the last holdouts?
[14:27] <seb128> mdeslaur, define "holdouts"
[14:27] <seb128> GNOME is revamping UIs over simply headerbars
[14:27] <mdeslaur> gnome apps held back to old versions
[14:27] <seb128> so maybe some of the GNOME 3.16 updates as going to be considered again problematic for us
[14:27] <seb128> mdeslaur, but currently yes
[14:31] <willcooke> qengho, out of my meeting - need me to try anything?
[14:31] <willcooke> qengho, have just checked, and it's only "odd" on my 2nd screen
[14:32] <willcooke> i.e move Chrm windows to laptop panel, layout menus etc etc all ok
[14:33]  * mdeslaur considers hardcoding G_ENABLE_DIAGNOSTIC=0 in old gedit for now...
[14:50] <mdeslaur> seb128: I am an anarchist: http://paste.ubuntu.com/10591179/
[14:51] <seb128> mdeslaur, is that the appropriate env variable? and didn't we say we want to disable those in GTK?
[14:52] <mdeslaur> seb128: well, it works for me :) It's really not a nice thing to do though, hopefully we'll disable them in gtk instead.
[14:52] <mdeslaur> seb128: I will preserve my sanity until then :)
[14:52] <mdeslaur> s/I/It/
[15:02] <seb128> larsu, desrt, ^ is that env the correct one to use?
[15:02]  * mdeslaur awaits screaming
[15:03] <desrt> yes
[15:03] <desrt> but you're evil
[15:03] <mdeslaur> desrt: I am an anarchist :)
[15:03] <seb128> mdeslaur, I would prefer that we disable those in GTK proper
[15:03] <desrt> mdeslaur: not a great big sea fan, apparently
[15:03] <seb128> I can have a look to that next week
[15:03] <desrt> seb128: i actually like mdeslaur's approach
[15:04] <desrt> since we recognise that gedit is a singularly special case
[15:04] <seb128> no we don't
[15:04] <desrt> i do :)
[15:04] <seb128> right
[15:04] <seb128> there is a class of tools you are likely to be run from a command line
[15:04] <seb128> editors being a common one
[15:04] <seb128> but gedit is not the only editor
[15:05] <seb128> and others are even more likely to not keep up with GTK deprecation than gedit which is part of GNOME
[15:05] <desrt> gedit is also special by virtue of the fact that we held it back
[15:05] <seb128> right
[15:05] <desrt> gedit _did_ keep up
[15:05] <desrt> we didn't ;)
[15:05] <seb128> but it's only the one of the only application that keep up with GNOME cycles
[15:06] <desrt> seb128: wait until you hear about what i'm breaking next ;)
[15:06] <desrt> larsu already hates it
[15:06] <seb128> lol
[15:06] <seb128> tell us!
[15:07] <desrt> nothing that will have much impact on the people in this channel
[15:07] <desrt> just changing the style of how gobject code is written
[15:07] <desrt> basically trying to get rid of all the GTK_IS_WIDGET GTK_WIDGET GTK_WIDGET_CLASS and so on sort of macros
[15:07] <seb128> making half of the apps that were doing things that used-to-work-but-shouldnt stop working?
[15:07] <desrt> and replacing them with things like g_typeof(GtkWidget)
[15:07] <desrt> nah... we're gonna have to maintain backcompat on this one for ... well, forever, i guess
[15:08] <seb128> good to know
[15:08] <desrt> and it's all compile-time anyway
[15:13] <Laney> is shell designed to hide decorations on transient windows or something?
[15:13] <desrt> depends on what the window requests
[15:14] <Laney> nothing special in this case
[15:14] <Laney> just commenting out transient_for gets them back
[15:24] <mdeslaur> desrt: I've changed the patch to only set G_ENABLE_DIAGNOSTIC if it's unset, so you can still debug by specifically setting it, is that better?
[15:24] <desrt> mdeslaur: yes
[15:24] <desrt> although to be honest, i'm not sure what else that variable does :)
[15:24] <desrt> mdeslaur: you did it via the 'overwrite' parameter, right?
[15:26] <mdeslaur> desrt: yes, via overwrite
[15:37] <willcooke> qengho, good news....
[15:37] <willcooke> qengho, rebooting didnt fix it
[15:37] <willcooke> ;)
[15:38] <willcooke> drop downs are also empty :/
[15:38] <didrocks> willcooke: do you think it worthes that we try a vm with 14.04?
[15:39] <willcooke> didrocks, if you've got one - that would indicate a general issue or "just me"
[15:39] <willcooke> didrocks, oh, except - it only seems to be my external monitor
[15:39] <didrocks> oh
[15:39] <willcooke> so maybe a live usb stick?
[15:39] <didrocks> yeah, so vm wouldn't help :/
[15:40] <didrocks> yeah, I can prepare one if you think it worths a double check
[15:40] <didrocks> or maybe qengho can try that setup?
[15:40] <willcooke> I'll try one first...
[15:40] <didrocks> I definitively don't have it on 15.04 + same chromium version
[15:40] <didrocks> oh first
[15:40] <didrocks> did you try on a guest?
[15:40] <willcooke> I'll try a live usb
[15:41] <didrocks> well, first try a guest
[15:41] <willcooke> oh
[15:41] <willcooke> yes
[15:41] <willcooke> plan
[15:41] <didrocks> that will give you some hint if it's your user setup
[15:41] <willcooke> brb
[15:43] <willcooke> hum
[15:43] <willcooke> s'ok in a guest session
[15:44] <willcooke> broken in two profiles under my session
[15:44]  * willcooke thinks about what he's installed
[15:44] <didrocks> two profiles -> one being new?
[15:44] <willcooke> both old
[15:45] <didrocks> can be a migration thing maybe, a fresh new one?
[15:45] <didrocks> or private mode
[15:45] <didrocks> to get if it's a desktop config issue or chromium at least
[15:45] <willcooke> private == broken
[15:46] <willcooke> dafu?
[15:46] <didrocks> ok, so user configuration that interfered…
[15:46] <willcooke> this is odd
[15:46] <Laney> try with --temp-profile
[15:46] <willcooke> broken
[15:47] <didrocks> I think X will be a nice guilty as it's about positionning, only one monitor on those independant X window
[15:47] <willcooke> wait
[15:47] <didrocks> rename .config/monitors.xml to something, restarting session?
[15:47] <willcooke> fixed it
[15:48] <willcooke> so it turns out I had "Scale for menu and title bars" on my external screen set to 0.85
[15:48] <willcooke> (it's been like that for, erm, 4 months)
[15:48] <willcooke> set it back to 1
[15:48] <willcooke> everything ok again
[15:49] <didrocks> ahah, and so you were only looking at the internal scren
[15:49] <didrocks> screen*
[15:49] <didrocks> phew
[15:49] <willcooke> if I set it to 0.875 again, everything goes screwy in Chromium, but nothing else/
[15:49] <didrocks> that's weird you only saw it with chromium though
[15:49] <willcooke> ??
[15:49] <willcooke> yeah
[15:49] <didrocks> I guess a lot of other apps would be broken
[15:49] <didrocks> like any app where you can have a popup menu?
[15:50] <willcooke> qengho, did part of your hidpi work take that scaling factor in to account?
[15:50] <willcooke> yeah, everything else I tried was a ok
[15:50] <willcooke> meh
[15:50] <willcooke> fixed
[15:50] <willcooke> oh - no
[15:50] <willcooke> not fixed
[15:50]  * didrocks doesn't like when things are working but we know it's not consistent
[15:51] <didrocks> (it's always stricking back in a worse way later on)
[15:51] <willcooke> no no, it is.  I forgot to click "keep this config" :D
[15:51] <didrocks> ahah
[15:51] <didrocks> you got reverted!
[15:51] <didrocks> playing the emotional lift game :p
[15:52] <willcooke> :D
[15:53] <willcooke> oki - I'm going to knock off early today.  Sun is shining, reviews are done
[15:53] <willcooke> email if you need anything gang
[15:53] <didrocks> enjoy your evening and week-end willcooke!
[15:53] <willcooke> and you :)
[15:54] <didrocks> thanks
[15:54] <willcooke> Oh - I'm in London at a sprint next week, so might be around, but not very engaged
[15:54] <didrocks> with your awesome wifi connection there
[15:54] <willcooke> haha!
[15:55] <didrocks> Laney: that means we can take a week off it seems :)
[15:55] <willcooke> at least wait til I've logged off
[15:55] <willcooke> cya
[15:55] <Laney> hrhr
[16:07] <pitti> seb128, Laney, ogra_: ah, we didn't bring this to closure -- should we unseed ubuntu-touch-customization-hooks for the time being to make the images build again? or just move its upstart dep to upstart-bin? (but that seems more dangerous to me)
[16:08] <pitti> or (for completeness) drop ubuntu-standard from ubuntu-desktop-next?
[16:08] <Laney> I'd just unseed it if I were you - the /custom/ stuff doesn't work there currently anyway
[16:09] <pitti> *nod*
[16:09] <Laney> so porting this job would be part of enablement
[16:09] <ogra_> right, we just need to keep in mind it needs fixing before we seed it back ... i'm scared we'll forget it and not have it in our planning then
[16:10] <didrocks> maybe just comment the line + add another comment on top?
[16:10] <ogra_> yeah, something like that
[16:10] <Laney> this isn't going to get forgotten
[16:10] <didrocks> ogra_: or trust Laney, he's young and has potential…
[16:10] <Laney> "why doesn't dconf work?"
[16:11] <ogra_> Laney, right, but that "why doesn't dconf work?" will only come up if you already had planned only three weeks for enablement of that intel tablet ... and now two days before deadline you realize that whole porting mess still has to be done
[16:12] <ogra_> this is what i fear ... i'm not scared that we forget it before makeing -next the default desktop ;)
[16:12] <Laney> you think that tablets are going to be enabled on top of desktop-next?
[16:13] <Laney> with no image based updates?
[16:13] <Laney> and no support for custom anything at all atm
[16:13] <ogra_> right, thats a point
[16:13] <ogra_> unseed it :)
[16:14] <pitti> Laney, ogra_: http://paste.ubuntu.com/10591613/ ?
[16:14] <ogra_> pitti, looks fine
[16:15] <pitti> wrt. the comments, I mean
[16:15] <ogra_> yeah
[16:15] <ogra_> wrt everything :)
[16:15] <pitti> ack, doing that then
[16:16] <pitti> at least I don't go to vac knowing that I broke images :)
[16:16] <ogra_> :)
[16:16] <pitti> (I mean even more than I already did!)
[16:16] <pitti> didrocks will save us all!
[16:16] <ogra_> i'll trigger a test build before EOD'ing
[16:16]  * pitti updates seeds
[16:16] <pitti> I mean, u-touch-meta
[16:17] <ogra_> you mean both :)
[16:17]  * didrocks runs far far far
[16:17] <ogra_> didrocks, coward !
[16:18] <didrocks> ogra_: no no, "already been there" :)
[16:18] <ogra_> haha
[16:32] <seb128> Laney, pitti, ogra_, no opinion about touch customization, I don't even know what that does ... let's see if the iso boots to a working desktop without it
[16:32] <ogra_> seb128, well, the custom tarball ships the apps
[16:32] <ogra_> (eventually all of them, currently only a subset)
[16:33] <seb128> ogra_, is that true on amd64 as well?
[16:33] <ogra_> i assume it will eventually ... not right now, that is why you dont really have many installed i guess :)
[16:34] <seb128> well, we install debs so that's fine
[16:34] <ogra_> right, until you switch to a snappy base
[16:36] <seb128> yeah, not for vivid
[16:36] <seb128> so we are fine for this cycle
[16:39] <Laney> it's like tweaking XDG_DATA_DIRS and stuff to add /custom/
[16:41] <seb128> is that package doing that?
[16:41] <seb128> is that needed for unity8 to work properly?
[16:42] <Laney> nah, we don't have that directory on next
[16:42] <seb128> k
[16:42] <Laney> it's so stuff in there can work properly
[16:42] <Laney> i'd bet that all 0 things are working right :P
[16:42] <seb128> lol
[17:11] <didrocks> ok guys, see you next week!
[17:11] <didrocks> seb128: safe drive back as well
[17:12]  * didrocks waves
[17:12] <seb128> didrocks, thanks, good w.e!
[17:12] <didrocks> and enjoy your holidays pitti :)
[17:12] <didrocks> thanks!
[17:15] <pitti> ah, I missed him
[17:15] <pitti> was in a meeting
[17:16] <Laney> hurry up gvfs build
[17:16] <Laney> got to go drill a hole before it goes dark
[17:17] <Laney> BUILDS, SHIP IT
[17:37] <seb128> tedg, hey, https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bugs?orderby=-id&start=0 has quite some apport activity recently, might be worth looking at it/cleaning
[17:39] <mdeslaur> seb128: FYI, I uploaded my gedit patch, I'll revert it if/when warning get disabled in gtk or if someone has a strong objection to it
[17:39] <seb128> mdeslaur, k, thanks
[18:03] <seb128> hum
[18:04] <seb128> is gdk_screen_get_monitor_geometry () supposed to return half of the real size when GDK_SCALE=2?