[04:29] <pitti> Good morning
[05:34] <hikiko> hi :-)
[06:47] <didrocks> good morning
[06:48] <pitti> bonjour didrocks !
[06:49] <didrocks> bonjour pitti :)
[06:50] <seb128> good morning desktopers
[06:50] <seb128> hey pitti, wie gehts?
[06:50] <seb128> re didrocks
[06:50] <didrocks> re seb128
[06:50] <pitti> hey seb128! gut, danke! und Dir?
[06:50] <seb128> pitti, auch gut, danke
[06:51] <seb128> a bit tired this morning though
[06:51] <pitti> j'ai me levé à 5:30, c'est trop tôt -- mais, beacoup de temps calm dans le matin :)
[06:51] <pitti> like for unscrewing debhelper before everyone else starts uploading again :)
[06:53] <seb128> hehe, I saw that on -changes
[06:53] <pitti> but I didn't manage to break devel, just -proposed; so no fun for xenial users
[06:54]  * pitti gives britney a cookie
[06:56] <seb128> :-)
[07:07] <hikiko> Hey pitti didrocks seb128
[07:07] <seb128> hey hikiko! how are you?
[07:07] <hikiko> I am fine :-) and you?
[07:08] <didrocks> hey hikiko
[07:08] <hikiko> Bonjour Didier
[07:15] <seb128> I'm good thanks
[08:52] <Trevinho> Morning
[08:54] <didrocks> good morning Trevinho
[08:55] <seb128> hey Trevinho
[08:55] <seb128> how are you?
[08:58] <willcooke> morning all
[09:01] <willcooke> larsu, I'm having trouble with borders on GeditCloseButton not doing what they are told, specifically radius.  But.. it looks like I can set the border on the GtkImage of the close button and that works better.  Is that OK?
[09:01] <seb128> hey willcooke
[09:01] <seb128> how are you?
[09:01] <didrocks> morning willcooke
[09:02] <seb128> willcooke, larsu was around until like 10 minutes ago, he went to the gym
[09:02] <willcooke> aint no thing, it can wait
[09:02] <seb128> willcooke, did you copy what the gedit-adwaita is doing?
[09:02] <seb128> I didn't pay attention to the borders much but that looked better to me that the non themed ones
[09:02] <seb128> well the ones in the sidebar documents list at least
[09:02] <seb128> you might be speaking of tabs or something else
[09:02] <Laney> morning
[09:03] <willcooke> seb128, yeah got that all sorted, just trying to match the theme as closely as possible from the old one specifically when you hover over a close button you get a border
[09:04] <seb128> k
[09:04] <seb128> hey Laney! how are you? getting over the cold?
[09:04] <willcooke> seb128, hrm, but good point - adawita is doing what I want actually
[09:05] <willcooke> seb128, also I've finished copying the bits over from Adwaita gedit to our theme, just need to get these close buttons done and we're good to go
[09:05] <seb128> \o/
[09:05] <seb128> let me know when you have that up
[09:05] <willcooke> will do
[09:05] <seb128> I can test it there and then start on the landing
[09:06] <Trevinho> seb128: so, so...
[09:06] <Trevinho> Hey didrocks
[09:06] <seb128> Trevinho, sooooo
[09:07] <Laney> seb128: it is more of a cough now
[09:07] <Laney> sooooooooooo I hope that is progress?!?!?!
[09:07] <didrocks> Laney: happy that you start feeling better! :)
[09:09] <willcooke> Laney, can you remind me what, if anything, we decided about libinput?
[09:10] <Laney> willcooke: that we thought tjaalton was handling it...
[09:10] <Laney> or would
[09:11] <willcooke> ah yes, and he said something along the lines of "it's pretty much necessary for the future, so we should try and get it in for 16.04"
[09:11] <willcooke> $customer asking about whether libinput would be in 16.04
[09:12] <didrocks> $customer is a customer with some dollars? :)
[09:13] <willcooke> :)
[09:14] <Laney> I'm sure that either way the OEM build would be able to have it
[09:14]  * Laney is using libinput driver already
[09:14] <tjaalton> xserver-xorg-input-libinput is in the archive, but in universe as nothing depends on it yet
[09:14] <Laney> hey tjaalton
[09:14] <willcooke> ah cool, thanks tjaalton
[09:14] <tjaalton> once the unity input config capplet supports it we can include it via xserver-input-all
[09:15] <willcooke> and then it would be available to anything that wanted to use it?
[09:15] <seb128> tjaalton, it replaces other drivers right?
[09:15] <seb128> are Debian/Fedora using it?
[09:15] <willcooke> Trevinho, or maybe seb128 can you comment on input config capplet ^^ ?
[09:15] <seb128> would we loose any feature by switching?
[09:15] <tjaalton> seb128: fedora is
[09:16] <tjaalton> no
[09:16] <tjaalton> it doesn't support wacom yet, but that's coming in libinput itself
[09:16] <tjaalton> but it would replace evdev and synaptics as a start
[09:16] <seb128> willcooke, well basically it means updating u-s-d/u-c-c code by importing what GNOME did, our versions are quite different so it's non trivial but still doable
[09:17] <seb128> tjaalton, how risky is the change?
[09:17] <seb128> like is likely to make trackpads not work correctly?
[09:17] <tjaalton> seb128: I think it's an overall improvement
[09:17] <seb128> or edge scrolling or some things work differently?
[09:17] <tjaalton> all work
[09:17] <seb128> k
[09:17] <seb128> do you have any cycle to backport the libinput conversion in u-s-d/u-c-c?
[09:18] <seb128> or is that something we should look at
[09:18] <seb128> I've that on my todolist but that list is long
[09:18] <tjaalton> I'm working on lts-wily backports atm
[09:18] <seb128> I'm also trying to backport the new wacom code from g-s-d, same story
[09:19] <tjaalton> the u-s-d/u-s-c fork is for good?
[09:20] <seb128> yes
[09:20] <seb128> well, for good ... at least for the coming LTS
[09:20] <seb128> I doubt it's relevant in unity8
[09:21] <tjaalton> no way to configure things?-)
[09:21] <seb128> in unity8?
[09:21] <Laney> there's a new settings app there
[09:21] <seb128> let's keep that for another day
[09:21] <tjaalton> hehe
[09:21] <tjaalton> ok
[09:21] <seb128> but yeah, there is ubuntu-system-settings
[09:21] <seb128> but it's limited, though there is ongoing work to make it fit for convergence
[09:22] <seb128> but that's not really important for the LTS/libinput discussion
[09:22] <tjaalton> right
[09:22] <tjaalton> anyway, I think debian would be ripe to do the switch, need to ask other folks on the team
[09:23] <tjaalton> they don't have unity to worry about :)
[09:23] <seb128> GNOME was talking about dropping the non-libinput code
[09:23] <seb128> so Debian is eventually going to follow by just updating
[09:26] <tjaalton> ok
[09:31] <seb128> tjaalton, what happens today if we start using libinput?
[09:31] <seb128> reading https://bugzilla.gnome.org/show_bug.cgi?id=740604 and looking to git, I'm not even sure we need u-s-d/u-c-c changes?
[09:32] <seb128> ah, it says they decided against the wrapper
[09:32] <seb128> so GNOME moved the handling in g-s
[09:32] <tjaalton> so it seems
[09:33] <tjaalton> I guess migrating now in xenial wouldn't be too dramatic
[09:33] <tjaalton> but at least all the forcepads I have need libinput, synaptics just doesn't work
[09:34] <tjaalton> or needs too much pressure to move the cursor
[09:34] <tjaalton> but the kernel driver is lacking something so right-button emulation isn't working, making forcepads still somewhat crippled..
[09:34] <tjaalton> but that's not related to the migration
[09:35] <seb128> yeah
[09:35] <pitti> hey Laney, how are you?
[09:36]  * pitti missed you coming "in"
[09:36] <pitti> Laney: ignore the autopkgtest mass failure emails, dealt with (that was me breaking debhelper)
[09:40] <seb128> tjaalton, willcooke, I think we would need to update u-s-d/u-c-c to use the new api/property for libinput (not idea what changed but reading the GNOME bug it seems the way to change configs probably changed)
[09:40] <willcooke> and then for synaptics, we just keep using the old drivers?
[09:41] <tjaalton> no libinput replaces the synaptics driver
[09:42] <willcooke> I R Confused.  So with libinput people with synaptics touchpads would have a bad time?
[09:42] <tjaalton> no
[09:43] <tjaalton> libinput replaces evdev and synaptics
[09:43] <willcooke> ohh
[09:43] <willcooke> so people with forcepads would be happier with libinput
[09:43] <willcooke> and everyone else probably wouldn't notice
[09:43] <Laney> would you remove those drivers?
[09:43] <tjaalton> probably
[09:43] <tjaalton> or my hw is just funky so that synaptics doesn't work well
[09:43] <Laney> or have code to handle both?
[09:44] <willcooke> how do we turn "probably" in to something more concrete that we can rely on for an LTS?  Is it a case of spending more time looking in to it?
[09:44] <tjaalton> no -evdev and -synaptics would still be around for some time, but probably gone before release
[09:45] <tjaalton> more folks using it. I know there have been issues with pointer acceleration code, but that's fixed by now I think
[09:45] <seb128> ok, so let's supposed we drop evdev and synaptics
[09:45] <tjaalton> libinput 1.2 will be released soon
[09:45] <seb128> and put libinput
[09:45] <seb128> what happens if we do no other change
[09:45] <seb128> if I go to u-c-c and change e.g edge scrolling
[09:45] <seb128> would that setting work?
[09:46] <tjaalton> not sure it would even show that
[09:46] <seb128> so we would regress functionnalities?
[09:46] <tjaalton> on the config side yes
[09:47] <tjaalton> two-finger scroll still works :)
[09:47] <tjaalton> at least here it just shows primary-button and double-click settings
[09:47] <tjaalton> nothing else
[09:48] <seb128> so my touchpad has edge scrolling and I like that better than 2 fingers scrolling
[09:48] <seb128> with libinput I wouldn't be able to use edge scrolling anymore?
[09:48] <tjaalton> dunno
[09:48] <tjaalton> it's easy to test, just install the driver
[09:49] <tjaalton> you can configure it with xinput
[09:51] <Laney> oh, missed pitti's hello - hi!
[09:51] <davmor2> laney he was in stealth greeting mode
[09:52] <seb128> tjaalton, seems the current code does XChangeDeviceProperty() calls to change settings
[09:52] <seb128> andXGetDeviceProperty()
[09:52] <seb128>         rc = XGetDeviceProperty (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), xdevice,
[09:52] <seb128>                                  prop, 0, 2, False,
[09:52] <seb128>                                  XA_INTEGER, &act_type, &act_format, &nitems,
[09:52] <seb128>                                  &bytes_after, &data);
[09:53] <seb128> willcooke, so I guess it's currently not in our backlog, we don't have anyone understand the pro/con and the work needed
[09:53] <seb128> if that's something we should work on we need to create an item for it and investigate those
[09:54] <seb128> so not on the path to happen unless we decide it should
[09:54] <seb128> tjaalton, ^
[09:55] <tjaalton> ok
[09:57] <willcooke> thanks seb128 tjaalton
[09:57] <willcooke> yeah, sounds like there is a lot of work to be done before we know
[09:57] <willcooke> maybe I can find another team to look in to that
[09:57] <seb128> I'm unsure about "lot"
[09:58] <willcooke> non-trivial then :)
[09:58] <seb128> right
[09:58] <seb128> brb, restarting without evdev/synaptic drivers and with libinput one, just to see
[09:59] <tjaalton> you don't need to remove anything btw
[09:59] <andyrock> willcooke: I need 5 more minutes
[09:59] <seb128> it might confuse u-c-c to think it can configure things where it can't
[10:00] <willcooke> andyrock, oki no worries - ping when you are ready and we can join the HO  ( <--- Trevinho, hikiko, seb128)
[10:01] <andyrock> waiting for the lecture break but the the teacher is kind of excited maximizing a log likelihood :D
[10:01] <Trevinho> willcooke: I'm in
[10:02] <willcooke> andyrock, :)
[10:04] <hikiko> willcooke, sec
[10:04] <hikiko> sorry
[10:06] <willcooke> andyrock, we're in the HO and we will get started
[10:07] <seb128> willcooke, tjaalton, so installed libinput, removed evdev/synaptic, restarted session, my edge scrolling isn't working anymore
[10:07] <seb128> the touchpad section of the settings also vanished
[10:07] <seb128> no "tap to click"
[10:07] <seb128> or "edge scrolling"
[10:07] <seb128> so yeah, needs porting to the new api
[10:08] <tjaalton> seb128: you don't need to remove anything, libinput just overrides the xorg.conf.d snippets evdev/synaptics provide
[10:08] <seb128> tjaalton, right, I just wanted to be a clean state to not confused the UI controls
[10:08] <seb128> to be on*
[10:08] <seb128> unsure what they check
[10:08] <tjaalton> sure
[10:09] <Laney> These have to be updated to look at the libinput xinput properties no?
[10:09] <andyrock> willcooke: looking for the link
[10:10] <Laney> Currently it looks for "Synaptics foo" for many foo
[10:10] <Laney> but xinput list-props x shows a lot of "libinput foo"
[10:13] <seb128> Laney, right, that's basically what I was saying/confirming
[10:13] <seb128> needs code change
[10:13] <seb128> and GNOME didn't do those for us since they moved the handling to g-s
[10:13] <Laney> they put it in gnome-screenshot?!?!?!?!?!?!?!?
[10:13] <seb128> :-)
[10:20] <seb128> libinput edge scrolling sucks :-(
[10:20] <seb128> I enabled it with "xinput set-prop 16 "libinput Scroll Method Enabled" 0 1 0"
[10:20] <seb128> but it's practically impossible to use on my latitude
[10:22] <tjaalton> how?
[10:23] <seb128> dunno, I've to have my finger really close from the border and press more than before
[10:23] <seb128> and it only detects it as a scrolling half of the time
[10:23] <seb128> http://who-t.blogspot.nl/2015/03/why-libinput-doesnt-support-edge.html
[10:23] <seb128> that is deprecated but it explained by libinput was not doing edgescrolling/how it conflicts with other features
[10:24] <tjaalton> yep
[10:24] <seb128> so maybe they detection/logic is different from what older drivers are doing
[10:24] <seb128> in any case it's harder to use on my machine
[10:25] <tjaalton> could just be a bug
[10:25] <seb128> yeah
[10:25] <tjaalton> seems fine on mine
[10:25] <seb128> well, it just confirms that it's not a trivial no-change swap
[10:25] <seb128> we are introducing new code and different behaviours
[10:25] <seb128> and different set of bugs
[10:25] <seb128> anyway, enough playing with that
[10:26] <seb128> it's enough to confirm that changing involves some wokr
[10:26] <willcooke> thanks a lot seb128, tjaalton, Laney
[10:26] <seb128> going to let willcooke&other managers decide if it's high enough that we need to budget cycles for it
[10:26] <seb128> willcooke, yw!
[10:26] <seb128> brb, rebooting
[10:27] <tjaalton> well, perhaps keep evdev/synaptics around and make it easy to switch back
[10:27] <Laney> who's going to do the u-c-c/u-s-d work?
[10:28] <willcooke> no one right now
[10:31] <Laney> I mean in theory
[10:31] <seb128> back
[10:32] <Laney> feel like it's sort of being glossed over but that is tough
[10:32] <Laney> yo
[10:32] <seb128> I missed some context I guess
[10:32] <Laney> I tried edge and it seems okay here, hate that mode though :P
[10:32] <willcooke> well, I imagine someone in our team would work on it
[10:32] <willcooke> seb128, <Laney> who's going to do the u-c-c/u-s-d work?
[10:34] <seb128> Laney, that was my comment about "up to the managers to decide how much of a priority it is and what resources get allocated to it"
[10:38] <Laney> ok
[10:39] <Laney> if we do no work then OEMs can still include it and preset their defaults in xorg.conf snippets btw, just users won't be able to configure it with a gui
[10:39] <seb128> right
[10:45] <willcooke> Laney, yeah good point.  If they do want it on in their images, I'm hoping that we can get them to commit to some of the work as well
[10:46] <Laney> willcooke: yeah - the feature tests mean that we don't expose any *broken* UI
[10:46] <Laney> - g_bit_nth_lsf@Base 2.12.0
[10:46] <Laney> - g_bit_nth_msf@Base 2.12.0
[10:46] <Laney> - g_bit_storage@Base 2.12.0
[10:46] <Laney> +#MISSING: 2.47.2-1# g_bit_nth_lsf@Base 2.12.0
[10:46] <Laney> +#MISSING: 2.47.2-1# g_bit_nth_msf@Base 2.12.0
[10:46] <Laney> +#MISSING: 2.47.2-1# g_bit_storage@Base 2.12.0
[10:46] <Laney> dddddddddddddddddddddddddddddddessssssssssrrrrrrrrrrtttttttttttt
[10:46] <seb128> desssrttt
[10:46] <larsu> desrt!
[10:47] <Laney> there's some weird shit going on around inline functions in this release
[10:47] <larsu> willcooke: I guess it should be ok. in general we try to avoid setting things on widget names directly
[10:47] <larsu> and use classes instead
[10:47] <Laney> larsu!!!!
[10:47] <larsu> morning all that I have missed
[10:47] <larsu> hi Laney :)
[10:47] <Laney> been @ gym?
[10:47] <larsu> ya. and going to lunch now
[10:47] <Laney> haha
[10:47] <seb128> larsu, enjoy!
[10:47] <Laney> tough day
[10:47]  * larsu will have to work more in the afternoon/evening today :)
[10:47] <larsu> thanks!
[10:47] <willcooke> larsu, got it, thanks.  Had a look at how Adawaita was doing it and saw that was the correct way, and actually, I just got it sorted
[10:48] <larsu> willcooke: very cool :)
[10:48]  * larsu thinks willcooke is shaping up to be a good theme maintainer
[10:48] <willcooke> it seems though that -gtk-gradient borders can't have radiused edges
[10:48] <larsu> hm really?
[10:48] <willcooke> I'm verrrrry slow
[10:48] <larsu> if css can do it, gtk should be able to as well
[10:48] <willcooke> yeah, at least border-radius doesn't have an effect
[10:48] <larsu> bug?
[10:48] <willcooke> maybe I need to slice them to make it work
[10:49] <willcooke> but that's too hard for me
[10:49] <larsu> :)
[10:49] <larsu> anyway - to late for my lunch date. see you in a bit
[10:49] <willcooke> l8r#
[10:57] <willcooke> background-color: rgb(255,0,0); is the CSS equivalent of print "XXXXX I am here!"
[10:57]  * willcooke <-- l33t hax0r
[10:58] <Laney> * { color: red; background-color: limegreen; } // IS THIS THING EVEN RUNNING?
[10:58] <willcooke> :)
[10:59]  * Laney has done this kind of thing before
[11:00] <Laney> when fixing o-s issues back in the day
[11:02] <seb128> Trevinho, btw did you meant to ask about something earlier with your "so, so..."?
[11:03] <Trevinho> seb128: no, as few mins before you asked how I was... :)
[11:03] <seb128> Trevinho, oh, sorry, I didn't read that as a reply, rather than as an opinion to a topic to discuss
[11:03]  * seb128 hugs Trevinho
[11:04] <Trevinho> :-)
[11:10] <seb128> Trevinho, did you find a way to deal with the matching issue with nautilus? btw did you see my comment about gedit/are you looking at that one as well?
[11:11] <willcooke> seb128, I want to check a couple of bits of styling before commiting these changes.  Can I just add a "padding: 10px" (or whatever it was in to gtk-widgets.css for testing?
[11:11] <willcooke> oh, this is for the file dialog
[11:12] <willcooke> not the normal file browser, the other one
[11:12] <seb128> sure, why not?
[11:12] <seb128> the sidepane widget is shared between nautilus and file-selector
[11:12] <seb128> I'm unsure what you are asking?
[11:13] <seb128> https://code.launchpad.net/~willcooke/ubuntu-themes/fix1515557/+merge/278423 ?
[11:13] <Trevinho> seb128: for nautilus https://code.launchpad.net/~3v1n0/bamf/safer-pid-desktop-registration/+merge/278461
[11:13] <seb128> cool
[11:13] <Trevinho> seb128: for gedit, I don't know... As I said yesterday we already use the _GTK_APPLICATION_ID (thanks to larsu's work) to use it as desktop-id... So not sure why it doesn't work
[11:14] <Trevinho> seb128: I didn't see the issue btw (yet)
[11:15] <willcooke> seb128, ah, this is the one I meant:  https://bugzilla.gnome.org/show_bug.cgi?id=758585
[11:16] <willcooke> I'll just hack that fix in so I can test gedit
[11:16] <willcooke> and make sure I don't commit it
[11:16] <seb128> willcooke, you can also upgrade gedit, that fix landed in xenial yesterday
[11:17] <willcooke> ah, even better, thanks seb128
[11:17] <seb128> yw
[11:20] <seb128> Trevinho, with gedit the issue is that if I dnd gedit from the dash to the launcher I gedit a gedit.desktop added to my launcher
[11:21] <seb128> but if I start gedit from a command line I get
[11:21] <seb128> _GTK_APPLICATION_ID(UTF8_STRING) = "org.gnome.gedit"
[11:22] <seb128> which leads to a new icon in the launcher
[11:22] <seb128> same if I open a document from gedit
[11:22] <seb128> ups
[11:22] <seb128> gedit->nautilus
[11:24] <Laney> seb128: could those theme tweaks go to the 3.18 branch too?
[11:24] <Laney> oh they did
[11:24] <Laney> nice ;)
[11:24] <seb128> righnt
[11:24]  * Laney needed to pull
[11:40] <seb128> willcooke, Laney, https://bugs.launchpad.net/gtk/+bug/1519778 just for info (corresponding bugzilla bug filed as well)
[11:41] <willcooke> thx seb128
[11:41] <seb128> yw
[11:43] <willcooke> hrm, my theme changes are working.  Back to the drawing board...
[11:44] <seb128> not working?
[11:44] <willcooke> my selectors arent matching
[11:44] <didrocks> seb128: I guess will feels that working is wrong :)
[11:44] <willcooke> oh
[11:44] <willcooke> *are not
[11:44] <seb128> charles, hey, any chance you could have a look to https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1261191 ? it seems like a good one to fix for the LTS
[11:44] <didrocks> "what, this is working, let's revert it" :)
[11:45] <seb128> hehe
[12:12]  * Laney switches on bbc parliament
[12:18] <Trevinho> Laney: what's happening?
[12:18] <davmor2> Sweet5hark: do you have a screenshot of what the icons in LO should look like on Ubuntu at all, I think I still see the gnome ones in kvm on the daily in live session on first start up but would like to be sure
[12:19] <Laney> Trevinho: a bit of political theatre, some budget cuts to be announced
[12:19] <Laney> seb128: thx for the bug
[12:23]  * Laney screams
[12:23] <Laney> sun just started reflecting off a window opposite
[12:23]  * Laney goes blind
[12:23] <davmor2> Laney: what is this sun of which you speak
[12:24] <Laney> you don't want it
[12:26]  * didrocks would want some sun now :(
[12:26]  * davmor2 doesn't believe Laney has it, you sure it is not a Police search helicopter light?
[12:40] <desrt> Good morning all
[12:41] <desrt> time to get my coffee, croissant, and a side of HIDEOUS ABI BREAKAGE
[12:41] <desrt> yum
[12:42] <Laney> hi desrt! :D
[12:43] <desrt> will take a look :)
[12:43] <Laney> maybe just a missing available annotation?
[12:43]  * Laney wants a croissant
[12:43] <desrt> ya.  visibility is the first thought that occurred to me too
[12:44] <desrt> since I'm fairly sure the definitions are being properly emitted
[12:44] <desrt> but seriously... the abi thing was third in that list for a good reason :)
[12:45] <didrocks> good morning desrt!
[12:45] <desrt> moin :)
[12:45] <xnox> =(
[12:45] <xnox> desrt, what abi breakage?!
[12:46] <didrocks> xnox: a gliby thingy
[12:46] <didrocks> xnox: http://irclogs.ubuntu.com/2015/11/25/%23ubuntu-desktop.html#t10:46
[12:47] <desrt> inlining in glib has been a disaster for a while -- we had inline versions in headers and backup versions in the .c file in case the compiler that you were using to build your project which included the headers didn't suport inlining
[12:47] <desrt> we gave up on that now since all compilers do inlining
[12:47] <desrt> so i cleaned up a lot of that mess, and tried to preserve the old versions for strict ABI compatibility
[12:47] <desrt> but clearly failed :)
[13:44]  * desrt escapes key-fob insanity
[13:44]  * desrt dives into ABI insanity
[13:46] <desrt> our building has massive keyfobs that double as garage-door-openers and i'm tired of carrying mine around... and i've long suspected that the transmitter and keyfob aspects of it operate separately... so i took it apart today to figure out which part of it was responsible for each
[13:47] <desrt> oddly enough, the thing stopped working after i took it out of the case
[13:47] <desrt> turns out the nfc/rfid bit is the back panel of the case itself
[13:49] <desrt> Laney: visibility was indeed the problem.  want a new release today?
[13:49] <desrt> (i already pushed the fix if you want to cherrypick it in the meantime)
[14:05] <Laney> desrt: probably a good idea, other distros might pick it up and not notice
[14:05] <willcooke> larsu, I'm going insane here.  My padding is being ignored for buttons in gedit, but everything else (like a test background colour) is being applied
[14:05] <willcooke> ?!
[14:05] <Laney> thanks for fixing
[14:05] <willcooke> any ideas?
[14:07] <willcooke> when I paste it in to the inspector it works
[14:07] <seb128> willcooke, what rule do you use?
[14:07] <willcooke> don;t understand "rule"
[14:08] <willcooke> css selector?
[14:09] <seb128> sorry, what lines do you add to the css
[14:09] <seb128> so we can try
[14:10] <willcooke> I'll pastebin it
[14:10] <larsu> willcooke: you can see in the inspector where a value comes from
[14:10] <larsu> in "style properties"
[14:10] <larsu> it tells you file and line nr
[14:10] <willcooke> larsu, it's blank
[14:11] <larsu> then your rule doesn't apply
[14:11] <willcooke> but the b/g colors *are* being applied
[14:11] <larsu> what is it? Do you have a branch?
[14:11] <willcooke> pastebin.ubuntu.com/13502453
[14:11] <willcooke> http://pastebin.ubuntu.com/13502453
[14:12] <larsu> hehe I was about to complain about the non-clickiness of that first link ;)
[14:12] <willcooke> :)
[14:12] <larsu> that's apps/gedit.css?
[14:13] <willcooke> yeah
[14:22]  * willcooke wonders if it could be some of the @xyz definitions being wrong for our theme
[14:23] <larsu> willcooke: ya, that seems to be it indeed (remove the "theme_" prefix)
[14:27] <willcooke> heh, thanks larsu, sorry to bother you with that
[14:28] <larsu> no worries :)
[14:28] <Laney> pitti: do you know if we're allowed to use backports in cloud deployed things?
[14:28] <Laney> trusty doesn't have a new enough lmdb, but I could backport it
[14:28] <pitti> Laney: I'm not sure that we even have a policy about what you can use
[14:29] <Laney> that sounds great to me ;-)
[14:29] <pitti> Laney: indeed trusty is pretty strongly recommended, but as long as you keep stuff updated backports sohuld be fine
[14:29] <Laney> I thought it was pretty tight
[14:29] <Laney> but actually I found a page about dev managed stuff even in prodstack
[14:29] <Laney> so if you get full control...
[14:29]  * Laney goes hog wild
[14:29] <pitti> Laney: I need a newer twitter-bootstrap3 for debci as well
[14:30] <Laney> pitti: I saw something where you wget a deb from the archive
[14:30] <Laney> that was great :P
[14:30] <pitti> Laney: yes, I manage autopkgtest myself, it's not CI managed
[14:30] <pitti> Laney: well, it's an utter hack, but *shrug*
[14:30] <Laney> pitti: this is prodstack, right?
[14:30] <pitti> yes
[14:30] <Laney> just the workers in scaling?
[14:30] <Laney> cool
[14:31] <pitti> Laney: the adt testbeds are in scaling; the workers themselves are on a PS instance
[14:31] <Laney> yeah sorry, that's what I meant
[14:31] <pitti> Laney: what are you charming up, OOI?
[14:31] <Laney> appstream extractor
[14:32] <Laney> another thing I'm not sure about is how to handle the cinder volume holding the archive mirror
[14:32] <Laney> it'd be a pain to have to start this from fresh each time
[14:32] <Laney> so maybe I can do it out of band
[14:32] <pitti> Laney: archive mirror?
[14:32] <Laney> juju doesn't seem to support this in the way I want yet
[14:32] <Laney> yeah, need a local one
[14:33] <pitti> Laney: ah, you want to attach a separate storage to your instance with that data
[14:33] <Laney> yes, it shouldn't be tied to the unit(?)
[14:33] <Laney> otherwise you have to re-mirror from scratch each time
[14:33] <pitti> Laney: where "each time" is just "when you redeploy", no?
[14:33] <pitti> which should happen like twice a year
[14:33] <pitti> so I wouldn't sweat that too much
[14:34] <pitti> Laney: and the mirror that you get in the cloud is pretty fast already
[14:34] <Laney> don't know
[14:34] <Laney> it's still a multiple hour operation
[14:34] <pitti> Laney: TBH I'd just start with setting up debmirror as part of your charm
[14:34] <pitti> Laney: you can upgrade a charm, you don't always need to re-deploy from scratch
[14:35] <Laney> I thought I might have the deploy script handle attaching a volume
[14:35] <pitti> welll, that indeed sounds elegant
[14:35] <Laney> i.e. do it out of band
[14:36] <pitti> Laney: I found that you can't charm quite a number of things anyway; you're going to need some deploy.sh script which invokes the various juju deploy, juju add-relation etc. commands, so you can do it there too
[14:36]  * Laney shrugs, will see, maybe it does prove to not be required that often
[14:36] <Laney> it would also be good to store the assets themselves in a resillient fashion
[14:36] <Laney> so after a redeploy we can serve the latest run until we catch up again
[14:37] <Laney> maybe I'm overthinking this for this early stage :)
[14:37] <pitti> Laney: so you can deploy your service
[14:37] <pitti> Laney: then use direct OpenStack commands to add the storage to your newly created machine
[14:38] <Laney> yeah, that bit should be fine
[14:38] <Laney> and I store the assets on this volume too
[14:39] <pitti> machine_no="$($(juju status myservice) | grep machine: | grep -o '[0-9]\+')"
[14:39] <pitti>     machine=juju-${env}-machine-${machine_no}
[14:39] <pitti> and then $machine is the thing to talk to with openstack commands line nova
[14:54] <Trevinho> desrt: hey, do you know what's the best way to get a gfile uri to be transformed to the actual path? I.e. I'd like to get the actual path from "trash://"
[14:59] <larsu> Trevinho: g_file_get_path()
[14:59] <larsu> it returns NULL though for things that don't have a path
[15:00] <Trevinho> larsu: tried in python but I get nothing
[15:00] <larsu> including trash://, I think
[15:00] <Trevinho> that's the thing
[15:00] <Trevinho> if you don't initialize it with a path, it won't work
[15:00] <larsu> trash isn't really a path...
[15:00]  * Trevinho wonders what nautilus uses
[15:00] <larsu> gio api
[15:01] <Trevinho> yeah, I know.. I mean, what it uses to get the proper path to show
[15:01] <larsu> where does it show that?
[15:01] <Trevinho> I mean, when you open trash:// in the location bar, it just open it as an ur and then fetches the children of that, or it maps to the real path to show?
[15:09] <larsu> Trevinho: it fetches the children with gio api
[15:09] <larsu> there's no path on the file system mapping to that
[15:10] <Trevinho> Mh, I see..
[15:10] <desrt> Trevinho: what larsu said
[15:10] <desrt> Trevinho: imagine you have http:// uri
[15:10] <Trevinho> Well the thing is that if you go in the trash, the you open a subfolder...
[15:10] <desrt> some GFile's simply do not have a path
[15:10] <Trevinho> nautilus open the actual paths
[15:10] <Trevinho> path*
[15:10] <Trevinho> the location is not trash://subfolder
[15:11] <desrt> that seems odd
[15:11] <Trevinho> err trash:///subfolder
[15:11] <desrt> curiously, i also see the same
[15:11] <desrt> nautilus may have some special code to do this
[15:11] <Trevinho> yeah, that's why I was wondering how to dothat...
[15:11] <desrt> pretty sure there is nothing on GIO API to support this
[15:12] <desrt>   standard::target-uri: file:///home/desrt/.var/lib/Trash/files/trashthis
[15:12] <desrt> so there you go
[15:12] <larsu> errr where do you see this?
[15:12] <Trevinho> standard::target-uri ?
[15:12] <desrt> gvfs-info
[15:13] <desrt> this is very strange, since the type of the thing is a directory
[15:13] <desrt> i wonder why i did that.....
[15:14] <larsu> no sorry, I mean in nautilus
[15:14] <desrt> i didn't do it.  it was hadess
[15:14] <larsu> I don't see the target-uri btw
[15:14] <desrt> see https://bugzilla.gnome.org/show_bug.cgi?id=667794
[15:16] <desrt> so there you go
[15:16] <desrt> Trevinho: my official answer is "it didn't used to do that but now it does and i don't really understand the reason"
[15:17] <Trevinho> mh, ok :-D
[15:17] <desrt> "so that totem can play DVDs from the trash"
[15:17] <desrt> (!)
[15:17] <larsu> wtf? Seriously?
[15:17] <desrt> that's what the commit says :)
[15:20] <larsu> sigh
[15:20] <desrt> anyway
[15:20] <desrt> Laney: new glib release is out
[15:21] <Laney> yay
[15:21] <desrt> hopefully this one isn't hideously broken
[15:21] <Trevinho> desrt: so.... There's no really way to get me the actual trash path?
[15:21] <desrt> Trevinho: but there is!
[15:21] <desrt> examine the standard::target-uri property, i guess
[15:21] <Trevinho> desrt: a part from going trhough children..
[15:21] <desrt> you can query it from g_file_query_info
[15:21] <Trevinho> desrt: there's nothing for gvfs-info trash:///
[15:22] <desrt> it has to be on a file in the trash
[15:22] <Trevinho> desrt: there's for gvfs-info trash:///trashed-child
[15:22] <desrt> trash:/// isn't an actual location
[15:22] <desrt> it is a combination of several locations (for example trash folders on removable media)
[15:22] <Trevinho> yeah, but I wanted to get from trash:/// -> file:///home/marco/.local/share/Trash/files/
[15:22] <desrt> different items can be in different actual locations
[15:22] <Trevinho> mh
[15:22] <desrt> if you want to know the homedir one, the answer is simple
[15:23] <desrt> by the spec it's in XDG_DATA_HOME/Trash/files
[15:23] <Trevinho> desrt: ok, that's what I wanted to use...
[15:23] <desrt> g_get_user_data_dir()
[15:23] <Trevinho> desrt: but you defined data_home on ~/.var/lib ?
[15:23] <larsu> Trevinho: what are you doing?
[15:23] <desrt> Trevinho: i set my XDG_DATA_HOME to that
[15:24] <Trevinho> larsu: launcher icons <-> storage windows matching
[15:24] <Trevinho> desrt: ok, then I'd go for that then
[15:24] <desrt> read http://standards.freedesktop.org/trash-spec/trashspec-1.0.html
[15:24] <desrt> but consider removable media
[15:24] <larsu> Trevinho: shouldn't that matching be on the uri, and not on the path?
[15:25] <Trevinho> desrt: yeah, that's the thig
[15:25] <Trevinho> larsu: in fact I was doing it using the URI...
[15:25] <desrt> just use GFile...
[15:25] <desrt> you do not want to reimplement the trash spec
[15:25] <larsu> nautilus windows tell you on dbus what they are showing right now (as a URI)
[15:25] <desrt> says someone who has implemented the trash spec
[15:25] <Trevinho> larsu: then... If you open nautilus trash and you go inside a trashed folder, nautilus sayus that you're in ~/.local/....
[15:26] <larsu> Trevinho: that's a bug
[15:26] <desrt> ya.. this is a combination of a nautilus bug and hadess being insane
[15:26] <Trevinho> larsu: that's what I'm using, but it's not using the URI for trash sub-folders
[15:26] <desrt> one of those two situations ought to be rectified
[15:26] <larsu> it should though
[15:26] <desrt> (perhaps both)
[15:26] <desrt> i can totally see the nautilus logic here
[15:26] <Trevinho> that's why I asked... otherwise my coed would have worked perfectly without caring about the actual trash uri
[15:26] <desrt> "did the user click on something that has a symlink destination?  go to it."
[15:26] <desrt> when the logic should be:
[15:26] <desrt> "did the user click on something that IS A SYMLINK AND has a symlink destination?  go to it."
[15:27] <desrt> why hadess sets symlink destination on a directory?  no idea.
[15:28] <Trevinho> desrt: so you'd say we should fix nautilus or..... just use a workaround in unity side?
[15:30] <larsu> fix nautilus :)
[15:30]  * larsu hides
[15:30] <desrt> Trevinho: i'm chatting with hadess.  i think we need to fix gvfs.
[15:30] <desrt> we should also think about fixing nautilus while we're at it
[15:32] <Trevinho> desrt: ok, thanks... Let me know what's the final decision...
[15:32]  * Trevinho drives back to Florence
[15:32] <seb128> Trevinho, safe drive!
[15:32] <Trevinho> snow allert :o
[15:33] <Trevinho> seb128: thanks
[15:41] <seb128> tedg, hey, do you remember what is the deal with bug #1165420? did we remove indicators content from the hud on purpose? or was it a side effect of the gmenu transition?
[15:45] <attente> hi, does anyone know or have a debian/watch file for github releases?
[15:52] <seb128> attente, ibus has one
[15:52] <seb128> https://github.com/ibus/ibus/releases .*/ibus(?:-|_|_v|V)(\d\S*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
[15:52] <seb128> unsure if it works though
[15:54] <attente> seb128: thanks, i will try it
[16:09] <xnox> checking for XMIRMODULES... no
[16:09] <xnox> checking whether to build Xmir DDX... yes
[16:09] <xnox> configure: error: Xmir build explicitly requested, but required modules not found.
[16:09]  * xnox needs help
[16:09] <seb128> xnox, where is that?
[16:10] <xnox> seb128, on s390x
[16:10] <seb128> robert_ancell would probably be your best bet but he's sleeping at this time
[16:10] <xnox> i guess i should skip it, just like it is skipped on arm64, powerpc and ppc64el
[16:10] <seb128> maybe bregma or ChrisTownsend or tedg can help you
[16:10] <seb128> yeah, probably
[16:10] <xnox> #shame -> i already bootstrapped mir
[16:59] <tedg> seb128, it was removed because it failed in user testing. The plan was to bring it back with additional info, but it never got implemented.
[17:00] <seb128> tedg, ok, seems quite some users liked/would like that (me included), I was wondering if that was something to "fix" for the LTS
[17:00] <seb128> I though it was buggy
[17:00] <seb128> not disabled on purpose
[17:00] <tedg> Sadly, no clue on Mir. Try #ubuntu-Mir
[17:01] <seb128> I would argue that the audiance that uses hud is probably not confused by indicators being listed in there
[17:01] <tedg> seb128, I am +1, I doubt there is anyone in design that remembers that user study anyway ;-)
[17:02] <seb128> would it be easy to re-enable? do you remember where that was changed?
[17:02] <tedg> seb128, it has been rewritten since...
[17:02] <seb128> oh, right :-/
[17:02] <seb128> tedg, thanks
[17:03] <seb128> so a valid wishlist but not likely trivial
[17:03] <tedg> But we now have an indicator registry, so it should be easier now.
[17:07] <seb128> tedg, k, let's see if somebody can pick it up as LTS polish, I put it on the list
[17:38] <didrocks> good night everyone!
[17:39] <willcooke> cya didrocks
[17:39] <didrocks> see you!
[17:55] <Trevinho> desrt: got anything from that discussion?
[17:55] <desrt> annoyingly, no
[17:55] <Trevinho> desrt: mh, so... going for a workaround for now
[18:03] <desrt> Trevinho: we're still chatting about it
[18:03] <desrt> Trevinho: but sure... more workarounds are cool too
[18:04] <Trevinho> desrt: well, I don't love them, but if we can't find a better solution upstream...
[18:04] <desrt> we can
[18:04] <desrt> but you haven't given much time
[18:04] <Trevinho> maybe :-)
[18:05] <Trevinho> I was wondering... In case of a subfolder trashed on an external device...
[18:05] <Trevinho> what's its uri?
[18:05] <Trevinho> I mean, trash://media-id/folder or what?
[18:10] <attente> seb128: could i submit a new package for upload to the archive?
[18:22] <Laney> glib uploaded to sync tomorrow, some first work on appstream charm pushed
[18:22] <Laney> LATERS
[19:13] <Sweet5hark> willcooke: fyi http://nabble.documentfoundation.org/Candidacy-Bjoern-Michaelsen-td4167393.html
[19:14] <willcooke> Sweet5hark, good stuff!  Good luck
[19:15]  * Sweet5hark starts kissing babies and buys a smear campaign on TV.
[19:55] <ricotz> Sweet5hark, lol, thumbs up
[20:48] <willcooke> alrighty!!!
[20:48] <willcooke> I have vanquished by Gtk theme foes with a combination of brute force and ignorance
[20:48] <willcooke> I'll finish it tomorrow
[20:48] <willcooke> g'night all