[03:35] -SwissBot:#xubuntu-devel- ::xubuntu-artwork:: [greybird] r527 Don't add padding to the buttonbox in notifications... (by Simon Steinbeiß) [13:44] ...So all the people interested in running xfce4-panel plan to run from git, no? Eg, no point in me sticking it in xfce4-gtk3? [13:48] Unit193: i guess not, the last release is quite up to date so it should be packagable [13:48] nothing really critical was added after 4.13.1 [13:49] and it would really be good to get some testing whether xfconf+panel are stable now [13:49] Right, compatible with xfconf is the reason I'd do it, but seems like there's not really much call for it. [13:53] Unit193: i might build -panel from git, but PPAs are useful to get the dependencies still [13:54] but i'm still on 16.04 and no plans to upgrade until 18.04 [13:56] I find it useful, but could probably package it myself for my own use [13:56] well, if you guys package it, put it in a PPA... [13:57] We should push it for testing if we are considering it and other 4.14 components for 18.04 [13:57] Fine, I can do that later today. [14:00] thanks a bunch! [16:54] bluesabre: yea - that :) [19:41] Hrm, now I'm seeing: W: APT had planned for dpkg to do more than it reported back (10 vs 13). Affected packages: evince:amd64 indicator-sound:amd64 [21:58] bluesabre: Is it just me or does xfsettingsd --replace not exactly work as well now? Seems to leave the older version around. [21:59] Unit193: I think it works... definitely develop using it [22:08] It's just restarts that don't seem to go as planned, otherwise seems fine yeah. [22:09] what does "not as planned" mean specifically? [22:09] As stated, leaves the older version running while starting a new one. [22:10] oh, sorry, now i understand what you meant there [22:10] that's odd [22:11] bluesabre: No rush for us, we missed FF. :/ [22:13] i'm contemplating how bad the idea is to try to target 18.04 for xfce 4.13.x [22:13] in case 4.14 isn't released until the [22:13] n [22:14] Developmental releases in a LTS release...Sounds painful, was a bit painful last time. [22:14] yeah i know [22:15] just sucks cause ppl cling to their LTSs for a long time [22:15] so we'll get bugreports for 4.12 for some time to come (which we will ignore) [22:15] Well...I mean, "long term" [22:15] Debian stable is even longer too. [22:16] yeah [22:16] I'd like to stage everything in xfce4-gtk3, though. [22:16] (sorry for not really participating much in the devel planning for 17.10) [22:16] Unit193: yeah, that sounds like a good idea [22:16] I see the convo is here, as it should be :D [22:17] It's just, I don't want to be running certain ones, and it feels backhanded pushing things I won't run myself. :3 [22:17] bluesabre: I suppose I should give you the honors with pa-plug next cycle? :P [22:17] which ones would you not want to run? [22:17] Unit193: Sure thing [22:20] ochosi: I wondered if, for merging the notification plugin, you'd use reposurgeon or if base git tools are easy enough. [22:20] Unit193: i tried with the git onboard tools, it works okayish [22:21] the history of both branches is there, the only downside is you have several commits that would never compile and conflicting histories for files that overlap (makefiles etc) [22:21] not sure any other tool could really handle this more gracefully without completely rewriting history with some black magic [22:21] or is reposurgeon a tool that does that..? [22:23] It's supposed to do voodoo with git. :3 [22:25] i'll take a look at it [22:27] at some point i was also considering to just do what bluesabre did with some of his other exploits and create a huge squashed commit [22:28] Unfortunate, but understandable. [22:28] fwiw i had the local histories of both branches in master already [22:39] http://paste.openstack.org/show/K1jqK4vtfBDrCLec7Nds/ look about right? :3 [22:44] * ochosi wouldn't know [22:45] Crap, OK.