[03:45] <robert_ancell> RAOF, do you know any history behind DRI3 and xserver-xorg-video-intel?
[03:48] <RAOF> robert_ancell: You mean - why we've disabled it?
[03:48] <robert_ancell> RAOF, yeah. Well, not enabled it (it is disabled by default)
[03:48] <RAOF> robert_ancell: I didn't follow closely, but it caused bugs.
[03:48] <robert_ancell> That was my assumption - just not ready for prime time.
[03:48] <robert_ancell> RAOF, do you know which clients make use of it?
[03:49] <RAOF> Mesa
[03:50] <robert_ancell> RAOF, do you know if anyone is shipping with it enabled yet?
[03:50] <RAOF> Nope.
[03:50] <RAOF> Maarten would be your man there.
[03:51] <robert_ancell> RAOF, cool, thanks for the info
[04:00] <robert_ancell> RAOF, hmm, I enabled DRI3 and nothing blew up. Any way of confirming that it's actually being used and not DRI2?
[04:04] <RAOF> Xorg.0.log should say something about DRI3
[04:04] <RAOF> For 100% confirmation I think you could try xtrace?
[04:07] <robert_ancell> RAOF, bingo. xtrace for the win
[04:08] <robert_ancell> RAOF, do you know if xtrace is alive upstream? It often doesn't know opcodes but the last time I looked at it I wasn't sure how to send a patch
[04:08] <RAOF> No idea, sorry.
[05:47] <didrocks> good morning
[06:11] <pitti> Good morning
[06:14] <didrocks> hey pitti
[06:17] <pitti> bonjour didrocks !
[07:14] <larsu> bonjour!
[07:17] <didrocks> pitti: still having some hope on the systemd fsckd thing? Seems like last email was pretty clear…
[07:17] <pitti> didrocks: from Kay? yeah :/
[07:17] <pitti> bonjour larsu!
[07:17] <didrocks> pitti: I guess the best course of action is to rationalize our patch with the additional fixes (all that in one patch)
[07:17] <pitti> didrocks: so it seems we'll have to move fsckd to the Debian branch then
[07:17] <larsu> morgen pitti! Wie geht's?
[07:17] <didrocks> and apply it against v219
[07:18] <didrocks> pitti: I can do the first draft, then, you can review?
[07:18] <pitti> didrocks: yeah; I hope that we don't have to patch s-fsck so much but that this can stay
[07:18] <pitti> didrocks: sure!
[07:18] <didrocks> pitti: let's see what the diff would be (it's mostly removals in s-fsck)
[07:18] <pitti> didrocks: btw, I tried with the fsck mock on my laptop yesterday, and I didn't see any progress :/
[07:19] <pitti> didrocks: it's not the "fixes from trunk" which I added yesterday, happens with either
[07:19] <didrocks> pitti: at boot?
[07:19] <pitti> yes
[07:19] <didrocks> weird
[07:19] <pitti> (with real plymouth)
[07:19] <pitti> I only saw the "Ctrl-C" message
[07:19] <didrocks> was working 2 days again with a real fsck here
[07:19] <didrocks> ago*
[07:19] <didrocks> hum
[07:19] <pitti> ah, good
[07:19] <pitti> well, I don't know what I messed up, at some point I need to reinstall my laptop
[07:20] <didrocks> pitti: anyway, with the rationalized patch, I'll give some try…
[07:20] <pitti> didrocks: maintaining the translations will be the most ugly part, I figure
[07:20] <didrocks> yeah
[07:20] <didrocks> not sure what we can do here…
[07:20] <didrocks> (already keeping that in a separate patch maybe?)
[07:23] <pitti> didrocks: what did we do in the plymouth themes? were these translatable at all?
[07:23] <pitti> didrocks: but yes, separate patch for those sounds better
[07:24] <didrocks> pitti: our plymouth themes are .script files
[07:24] <didrocks> pitti: no i18n support
[07:24] <didrocks> that's why in addition to the machine parsable data, we send the l10n strings
[07:26] <pitti> didrocks: right; I meant it wouldn't be too much of a regression if we would drop them in the future
[07:26] <pitti> although it'd be a shame
[07:26] <didrocks> pitti: yeah, that's a possibility, but still a regression from the user POV
[07:26] <didrocks> pitti: should we revert to "c" btw?
[07:26] <didrocks> for cancelling
[07:26] <didrocks> as we did in the past
[07:26] <didrocks> as upstream doesn't care anymore, this change is now useless
[07:27] <seb128> hey didrocks larsu pitti
[07:27] <didrocks> (shame for ctrl+c, took some time to figure out how the protocole handled it specially… as it was requested upstream)
[07:27] <didrocks> re seb128
[07:31] <pitti> didrocks: I don't mind much TBH; if you want to switch back to C, please do
[07:32] <didrocks> pitti: ok, I'll try to handle this
[07:32] <didrocks> pitti: on the cancel only showing, it was with our ubuntu theme, right, not a debian one?
[07:33] <didrocks> (in that case, it's normal that you didn't get any progress)
[07:33] <willcooke> o/
[07:33] <didrocks> hey willcooke
[07:34] <pitti> didrocks: right, standard vivid desktop
[07:36] <seb128> hey willcooke
[07:43] <seb128> seb128q, hey
[07:44] <willcooke> ???
[07:45] <larsu> seb128 greets his alter-ego
[07:45] <didrocks> willcooke: he's broken
[07:46] <didrocks> need to reboot him
[07:46] <larsu> morning willcooke :)
[07:46] <seb128> lol
[07:46] <TheMuso> Hey folks. :)
[07:46] <larsu> didrocks: can you reach the power button from where you are?
[07:46] <larsu> hi TheMuso!
[07:46] <didrocks> larsu: pushing it for 5s right now
[07:46] <seb128> larsu, trying to reproduce that "notify-osd notification doesn't go away" people reported
[07:46] <seb128> seems it's quassel irc users
[07:46] <larsu> didrocks: lol
[07:46] <larsu> seb128: oh?
[07:47]  * larsu mumbles something about dreading to look at that code base again
[07:48] <willcooke> hey TheMuso
[07:52] <seb128> larsu, you are safe
[07:52] <seb128> $ dbus-monitor interface=org.freedesktop.Notifications | grep quassel
[07:52] <seb128>    string "quassel"
[07:52] <seb128>          variant             string "quassel"
[07:52] <seb128>    string "quassel"
[07:52] <seb128>          variant             string "quassel"
[07:52] <seb128>    string "quassel"
[07:52] <seb128>          variant             string "quassel"
[07:52] <seb128> quassel sends notifications several time a second for ever
[07:52] <larsu> seb128: quassel quassels too much
[07:53] <seb128> seems so
[07:53] <larsu> (quassel is chatting in German)
[07:53] <larsu> but you knew that ;)
[07:53] <seb128> :-)
[07:54] <seb128> cyphermox, ^ just a fyi, your notify-osd issue from the other day, it's a quassel bug
[08:02] <seb128> cyphermox, https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1442005
[08:04] <willcooke> g'night TheMuso
[08:05] <TheMuso> willcooke: Later. :)
[08:05] <didrocks> pitti: keeping debian/patches/Add-gettext-support.patch separated for now, unsure if they are not going to keep it
[08:06] <pitti> didrocks: yes, sounds good
[08:06] <Laney> hey ho
[08:06] <pitti> hey Laney, how are you?
[08:06] <didrocks> morning Laney
[08:06] <Laney> feeling alright thanks pitti
[08:06] <Laney> although!
[08:07] <Laney> I went to donate blood last night and got denied because my iron was too low
[08:07] <Laney> and the shocking thing is that the person suggested this may be because I drink too much tea
[08:07] <Laney> which apparently affects iron absorption
[08:08] <Laney> hey didrocks
[08:08] <Laney> what's up?
[08:08] <pitti> Laney: oh, wow
[08:08] <pitti> Laney: weren't you in that program to test whether the interval between donations could be reduced?
[08:08] <seb128> didrocks, pitti, https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1441883 might be something for you?
[08:09] <seb128> Laney, hey
[08:09] <pitti> seb128: boot bugs? go away! :-)
[08:09] <seb128> lol
[08:09] <pitti> j/k, /me looks
[08:09] <seb128> "Failed to isolate default target, freezing."
[08:09] <seb128> pitti, danke
[08:10] <Laney> pitti: indeed, so could also be related to going more frequently
[08:10] <seb128> Laney, time for coffee man:
[08:10] <pitti> ah, probably some fallout from the /e/X/default-display-manger handling
[08:10] <Laney> but they'll only have an idea of that when looking at the whole dataset I suppose
[08:10] <pitti> Laney: yeah, I had trouble keeping up my iron even with 3 month intervals
[08:10] <seb128> pitti, yeah, what I though
[08:11]  * Laney is reading a study from the tea advisory council which is trying to rubbish this theory ;-)
[08:13] <seb128> lol
[08:13] <didrocks> pitti: deleting lightdm should empty /e/X/d-d-m, right?
[08:13] <pitti> didrocks: ideally yes; I'll try to reproduce this in a bit
[08:14] <pitti> disabling the login screen should be easier (like, just removing /e/X/ddm), but  I guess installing the package should still not render the system unbootable
[08:14] <pitti> I figure it's trying to start display-manager.service and fails
[08:16] <didrocks> pitti: it's Wants=display-manager.service
[08:16] <didrocks> though
[08:17] <didrocks> ah
[08:17] <didrocks> pitti: I think I get it
[08:17] <didrocks> it's the failsafe mode
[08:17] <didrocks> Requires=display-manager.service
[08:17] <didrocks> OnFailure=failsafe-graphical.target
[08:17] <didrocks> (for graphical target)
[08:17] <didrocks> I wonder how we can make this elegant
[08:18] <didrocks> as the main point is "you wanted to have a graphical system (graphical.target), no graphics -> failsafe"
[08:21] <pitti> didrocks: hm, perhaps some Condition? could we make it ConditionFileNotEmpty=/e/X/d-d-dm or so?
[08:21] <pitti> didrocks: oh, d-d-m still has lightdm even after purging
[08:23] <didrocks> pitti: ok, so double issue :p
[08:23] <didrocks> pitti: ConditionFileNotEmpty? you can't express that to tell "only fallback if file not empty"
[08:24] <didrocks> it will not executed graphical.target is /e/X/d-d-m empty
[08:24] <didrocks> which is the default target, so I guess it will fail and trigger failsafe as well, no?
[08:26] <pitti> didrocks: I mean, if removing all display managers woudl make d-d-m empty, we could check on that and not run the fallback at all
[08:26] <pitti> (I have some trouble understanding what you meant to say, sorry)
[08:27] <pitti> didrocks: how is the fallback implemented right now, OOI? perhaps we did that wrong?
[08:27] <didrocks> pitti: shouldn't then multi-users.target be the default, rather?
[08:27] <didrocks> pitti: so, graphical.target Requires=display-manager.service/OnFailure=failsafe-graphical.target
[08:27] <pitti> it feels like display-manager.service should have something like OnFailure=ourfallback.service ?
[08:28] <pitti> didrocks: well, maybe, but graphical.target only Wants=display-manager.service, so if that doesn't exist, it ought to be ok
[08:28]  * pitti needs to read the error in more detail
[08:28] <didrocks> pitti: not sure we can extends display-manager.service though, it needs a try
[08:28] <pitti> didrocks: oh, requires; I thought it's wants
[08:28] <didrocks> as display-manager.service is in /etc
[08:28] <didrocks> and our extension for OnFailure would be in /lib
[08:29] <didrocks> let me give it a try
[08:29] <pitti> didrocks: that should work
[08:29] <pitti>  systemctl cat display-manager.service
[08:29] <pitti> # /lib/systemd/system/lightdm.service
[08:29] <pitti> didrocks: ah right, cat resolves symlinks
[08:29] <didrocks> pitti: let me give it a try
[08:31] <didrocks> pitti: seems to work
[08:31] <didrocks> so, /lib/systemd/system/display-manager.service.d/xdiagnose.conf containing OnFailure=failsafe-graphical.target
[08:31] <didrocks> and this extends the Alias display-manager.service, in /etc
[08:32] <didrocks> pitti: I'll handle the failsafe part of the bug, but /e/X/d-d-m needs to be empty still
[08:32] <didrocks> I guess
[08:32] <pitti> didrocks: ok, I can handle that part
[08:32]  * didrocks stops his systemd/fsckd rebasing
[08:33] <pitti> didrocks: but if display-manager.service doesn't exist at all, why would d-d-m need to be empty? if we just make it OnFailure=, display-manager.service wouldn't start at all?
[08:33] <pitti> didrocks: nah, don't interrupt stuff, it's not *that* urgent
[08:33] <didrocks> pitti: well, I'm in that context
[08:33] <didrocks> pitti: display-manager.service will exist, by the generator
[08:34] <didrocks> hum, or maybe not
[08:34] <didrocks> one sec
[08:34] <didrocks> needs to check, I guess I check for the unit
[08:34] <pitti> didrocks: the boot fails because it doesn't exist :)
[08:34] <pitti> didrocks: I added an xdiagnose task with a very short summary
[08:34] <didrocks> pitti: yeah, but then, I shouldn't create the symlink
[08:34] <didrocks> thx!
[08:35]  * pitti hugs didrocks, thanks for that (I'm not that familiar with xdiagnose)
[08:36] <didrocks> pitti: ok, we don't create display-manager.service if /e/X/d-d-m does refer to garbage (an non existing unit)
[08:36]  * didrocks hugs pitti back
[08:36] <didrocks> pitti: so, would be better to clean it up, I guess, but not required
[09:00] <didrocks> pitti: uploading the fix
[09:00] <pitti> \o/
[09:35] <seb128> happyaron, hey, are you looking at https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1439202 ?
[09:35] <seb128> happyaron, it's in the top 5 vivid issues for the week
[09:36] <seb128> cyphermox, https://errors.ubuntu.com/problem/91da1afe1d626059f88ff4a6f225718a2e20ed3d ... seems like your fix didn't really fix it?
[10:28] <happyaron> seb128: I'm trying to sort out my ticket issue...
[10:28] <happyaron> getting some trouble
[10:29] <happyaron> that's on the top on my list
[10:29] <happyaron> (means the bug)
[10:29] <happyaron> will deal with it this night
[10:31] <GunnarHj> Can somebody please sponsor bug #1441629? (The queue is long, and it's soon final freeze.)
[10:41] <ricotz> hey desktopers :)
[10:43] <ricotz> didrocks, hi, would you mind proposing bamf in *debian* to be maintained by pkg-mate? By sending a proposal to "MATE Packaging Team <pkg-mate-team@lists.alioth.debian.org>"
[10:43] <didrocks> ricotz: sure, can do
[10:44] <didrocks> any formal template or free-form is enough?
[10:44] <ricotz> didrocks, thanks, no idea if there is a formal process to change owner-ship of an package
[10:45] <Laney> just get someone to upload it and change the maintainer
[10:45] <didrocks> sounds easier this way then, ricotz, doing this? ^
[10:45] <ricotz> didrocks, i guess just a few lines regarding the fact isn't updated and outdated
[10:45] <Laney> it is orphaned, they can just do it
[10:45] <Laney> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779565
[10:45] <didrocks> yeah, I got it orphaned recently
[10:46] <ricotz> didrocks, debian-mate wants some kind of on-the-record statement to not step on someones toes
[10:46] <Laney> unnecessary
[10:46] <Laney> they should just adopt the package
[10:47] <didrocks> email sent, if that can make them happy :)
[10:47] <ricotz> Laney, didrocks, thanks!
[10:47] <didrocks> yw!
[10:47] <Laney> https://www.debian.org/devel/wnpp/#l3
[10:47]  * didrocks is all about people feeling confortable
[10:48] <Laney> they should know how the procedures work
[10:48] <Laney> orphaned package -> someone take this
[10:49] <Laney> interesting that mate wants bamf ...
[10:49] <didrocks> well, wnck isn't enough for windows matching
[10:49] <didrocks> they propbably wants better icons in the status bar :)
[10:49] <didrocks> and so matching desktop files
[10:50] <Laney> yes i'm sure they want to do matching with it
[10:50] <Laney> still interesting
[10:50] <ricotz> Laney, it is required by plank ;)
[10:51] <Laney> what is that?
[10:51] <ricotz> a dock/launcher application
[10:52] <Laney> i see
[11:43] <didrocks> pitti: I'm almost done, but I'll do multiple checks first. More complex due to recent trunk changes
[11:44] <seb128> happyaron, thanks
[12:16] <Laney> heh
[12:16] <Laney> re-debugging a FTBFS that I fixed in October
[12:16] <Laney> bring back daily landing!
[12:21] <didrocks> YEAH \o/
[12:21]  * didrocks has some FTBFS issues as well, I wonder if it's not an autotool dep
[12:21] <Laney> what kind?
[12:22] <Laney> i'm just browsing the archive rebuild + fixing stuff
[12:24] <didrocks> Laney: I think it's a -j4 issue (and so a dep), I'm rebuilding without it
[12:24] <didrocks> it's still this fsckd-out-of-trunk followup
[12:24] <seb128> Laney, what was defined that datadir in g-t and stopped doing so?
[12:24] <seb128> Laney, just to know if we can look for similar cases
[12:26] <Laney> didn't find where it came from
[12:26] <Laney> all the autotools stuff is the same version :(
[12:33]  * Laney diffs the build deps
[12:42] <nessita> hello everyone, quick question about LXC's in vivid: I just installed all updates, and the running LXC I had was killed by:
[12:42] <nessita> The system is going down for halt NOW!
[12:42] <nessita> SIGPWR received
[12:42] <nessita> I re-started it, and lxc-ls says is running, but it has no IP
[12:43] <nessita> sca-trusty                 RUNNING  -     -     -       NO
[12:43] <nessita> so I can not ssh into it. Any ideas?
[12:45] <Laney> seb128: aha, intltool
[12:47] <Laney> i'll see if there are more of these
[12:48] <seb128> k
[12:48] <Laney> looks like they didn't consider that intltool.m4 is an interface
[12:48] <seb128> Laney, should I try looking if there are some desktop build issues I can work on? or having several of us doing that is just going to lead to duplicating work?
[12:49] <seb128> Laney, they = dobey? ;-)
[12:49] <Laney> ^o)
[12:50] <Laney> was in 2013, probably can forgive him
[12:50] <seb128> hehe
[12:53] <Laney> seb128: if you want to look at this stuff, there's a gcc5 test build too
[12:53] <Laney> i'm looking at the normal toolchain one
[12:54] <seb128> Laney, ok, I can have a look to that
[12:57] <dobey> huh?
[13:01] <seb128> dobey, http://launchpadlibrarian.net/202626076/gnome-bluetooth_3.8.2.1-0ubuntu11_3.8.2.1-0ubuntu12.diff.gz
[13:02] <dobey> hmm that's odd
[13:03] <Laney> https://bazaar.launchpad.net/~intltool/intltool/trunk/revision/742
[13:07] <didrocks> pitti: hum, I can build successfully with -j1, but can't with -j4…
[13:07] <dobey> Laney: ah, so the problem is that the gnome-bluetooth build is running autoreconf, but isn't re-running intltoolize i guess; so you end up with a configure script that contains the newer macro bits, but you have the old Makefile.in.in
[13:07] <didrocks> linking issue (probably an order thing)
[13:08] <didrocks> I wonder why, doesn't seem I changed Makefile.am at all
[13:09] <didrocks> pitti: did you get this kind of issues with gpb (like timestamp?)
[13:13]  * didrocks does a boot test
[13:14] <Laney> dobey: ya, I went for this one but intltoolize would also work
[13:14]  * Laney goes to lunch
[13:22] <pitti> didrocks: no, I always build with -j4, I never ran into issues
[13:22] <pitti> didrocks: what's the particular output?
[13:24] <didrocks> pitti: just that it doesn't find fsckd.o, will paste now that I rebase on experimental in some minutes
[13:24] <didrocks> pitti: otherwise, all works well: cancellation (kept Control+C), translations, progress report…
[13:25] <didrocks> (with the binaries compiled with -j1)
[13:44] <didrocks> pitti: http://paste.ubuntu.com/10782782/
[13:44] <didrocks> pitti: works fine with a clean -j1 though :/
[13:45] <didrocks> as you can see, src/fsckd/fsckd.o builds successfully…
[13:47] <didrocks> pitti: oh, I think I got it, fixing…
[13:49] <pitti> didrocks: hm, that indeed looks like a missing dep somehwere in the makefile?
[13:50] <didrocks> pitti: yeah, found and fixed I guess
[13:50] <didrocks> rebuilding to ensure
[14:12] <seb128> larsu, back?
[14:13] <seb128> larsu, can you have a look to https://code.launchpad.net/~yuningdodo/unity-control-center/unity-control-center.lp1248720-block-power-callback-unless-its-triggered-by-user/+merge/255041 and comment on whether you think it's right (the associated bugs as some details about GNOME versions and how upstream is (not) impacted (anymore)
[14:18] <ochosi> Laney: btw, could you ping me if you decide on whether to ship the patch from this bug or not? https://bugzilla.gnome.org/show_bug.cgi?id=746222
[14:18] <Laney> ochosi: aye aye, I think larsu was going to check it out
[14:19] <ochosi> Laney: thing is, we should probably add an additional class/style to our themes for that, otherwise it won't look very good
[14:19] <ochosi> okeydokey
[14:19] <Laney> feel free to build a test package and do this in advance
[14:19] <Laney> you'll definitely need it at 3.16 time in any case
[14:19] <seb128> larsu, Laney, ochosi, Trevinho, btw, is bug #1441975 a gtk or a theme or a compiz issue?
[14:19] <seb128> context menus issue
[14:20] <ochosi> my money is on compiz
[14:20] <seb128> lol
[14:22] <ochosi> i think without compositor, you can't get those shadows
[14:22] <ochosi> but theoretically it could also be a theme issue. i wonder though why it would be limited to nautilus then
[14:22] <seb128> it's not
[14:22] <seb128> it just got reported there
[14:22] <ochosi> oh, so no shadows underneath any context menus in gtk3?
[14:22] <seb128> right
[14:22] <seb128> works with gtk2 apps though
[14:23] <Trevinho> seb128: hmmhmh
[14:23] <ochosi> then if it's for all gtk3 apps it's likely the theme
[14:23] <seb128> larsu, ^
[14:23] <ochosi> (sorry for the flip-flop :))
[14:23] <seb128> hehe
[14:23] <seb128> no worry
[14:23] <Trevinho> seb128: should be gtk theme issue, as gtk3 now does that client side
[14:24] <ochosi> lemme test that in xubuntu real quick...
[14:24] <seb128> Trevinho, ochosi, thanks
[14:24] <ochosi> yes, definitely a theme issue
[14:24] <Trevinho> seb128: so, the fact is that we should add client shadows only to menus it seems
[14:24] <Trevinho> or... We make sure that compiz does that again
[14:24] <ochosi> i have shadows there with greybird in gtk3, but not with ambiance
[14:24] <Trevinho> ochosi: yeah, that's doing it on client side
[14:24] <ochosi> i think that is the way to go
[14:25] <ochosi> you can really tweak those shadows nicely with css
[14:27] <ochosi> if i'm not mistaken, this should be it: https://github.com/shimmerproject/Greybird/commit/b9f9b0826195ad115b56724326aa0d3e91063dd4
[14:28] <ochosi> yup
[14:29] <ochosi> that's it, just tested it successfully with ambiance
[14:29] <ochosi> seb128: ^
[14:29] <ochosi> also, CSD is quite unusable outside of Unity (or: without compiz) with Ambiance/Radiance
[14:29] <ochosi> no shadows, no borders...
[14:30] <ochosi> that's a bit sad, other than that, Ambiance works great with Xfce
[14:30] <seb128> ochosi, thanks
[14:30] <seb128> ochosi, is that a theme issue as well?
[14:31] <ochosi> but i guess you guys stuck to compiz drawing all those shadows
[14:31] <ochosi> yeah
[14:31] <ochosi> it is
[14:31] <seb128> Laney, larsu, ^ can you add your list to look at getting something similar to that in our themes for vivid?
[14:31] <Laney> makes sense
[14:31] <ochosi> Ambiance: http://i.imgur.com/BZqbCOr.png
[14:32] <ochosi> Greybird: http://i.imgur.com/51Sz1SF.png
[14:32] <didrocks> rebooting for finale testing
[14:32] <ochosi> the difference is a few lines in your gtk-widgets.css
[14:33] <ochosi> (plus disabling compiz' shadows for CSD apps i guess)
[14:34] <Trevinho> ochosi: we can't disable compiz shadows yet
[14:34] <didrocks> pitti: ok, seems to work well (direclty copied the binaries from the experimental branch), the set of patch is at http://people.canonical.com/~didrocks/fsckd-out-trunk/
[14:34] <Trevinho> ochosi: but you can add a css rule only for menus
[14:35] <didrocks> pitti: this includes the new workflow that I implemented a month ago (the patch which was never reviewed by upstream…)
[14:35] <ochosi> Trevinho: i see. well the commit in greybird i pointed you to does only that, so it's all you really need.
[14:35] <didrocks> pitti: that + flattening all the patches while keeping gettext support and translations separated for easyness (and taking latest potential trunk changes, reverting some post-219 changes that they made with library moves)
[14:36] <didrocks> pitti: so, all in all, should be good, I can rebase on the ubuntu branch, I will need anyway, as I think one or two autopkgtests are impacted by the direct fsck -> systemd-fsckd connection
[14:36] <didrocks> pitti: but I would appreciate a first quick look by ourself so stamp that all looks good first!
[14:36]  * didrocks now goes for a run
[14:36] <didrocks> (phew)
[14:38] <seb128> didrocks, enjoy!
[14:38] <seb128> I'm going to do the same in a bit
[14:38]  * ochosi tries not to be a copycat while at the same time going for the run which he planned too...
[14:39] <didrocks> seb128: enjoy as well :)
[14:39] <seb128> ochosi, :-)
[14:39] <seb128> didrocks, thanks
[14:40] <pitti> didrocks: rebasing> that's ok, I usually do it the other way around (rebasing ubuntu changes on top of experimental)
[14:40] <pitti> didrocks: so landing this in exp only is fine
[14:40] <Laney> mardy: yo, any chance you could take a look at the libsignon-glib build (test) failure in vivid?
[14:40] <didrocks> pitti: ok, so mind doing this, then I pull and fix eventual failing autopkgtests?
[14:41] <didrocks> pitti: yeah, I know you rebase everytime the ubuntu branch, my git reset origin/ubuntu --hard I have to do with the git branch are there to proove it :p
[14:44] <pitti> didrocks: 0001-Add-fsckd-patch-prepared-to-get-out-of-upstream-trun.patch  removes the old patches from the series, but not actually from debian/patches/ ?
[14:44] <pitti> ah, that's in 0003
[14:44] <pitti> I think the removal should be in 0001, and 0003 just the fuzz
[14:45] <pitti> but I can do that
[14:48] <pitti> didrocks: ok; I still hope that at least some parts of s-fsck.c will stay, it's a rather intrusive diff that way
[14:49] <pitti> didrocks: pushed (with 0003 merged into 0001), many thanks!
[14:51] <Laney> mardy: (filed bug, assigned you)
[15:00] <larsu> seb128: ya back for a while but was just having a tea with faina (lots to talk about)
[15:00] <larsu> seb128: the shadow thing is moot if we disable csd on unity, like Trevinho suggested
[15:00] <seb128> larsu, no hurry, enjoy your tea :-)
[15:00] <larsu> done now :)
[15:01] <seb128> larsu, saw the theme change ochosi suggested?
[15:01] <seb128> I've no real opinion on how to fix it, but seems like we should address it for vivid
[15:01] <seb128> it's quite visible (once you got told about it, show how much we look at UI details in our daily use here :p)
[15:02] <larsu> no shadows under context menus you mean?
[15:02] <seb128> yes
[15:02] <larsu> ya indeed :)
[15:02] <seb128> well around menus rather
[15:02] <larsu> is there a patch?
[15:02] <seb128> byt yeah
[15:02] <seb128> larsu, https://github.com/shimmerproject/Greybird/commit/b9f9b0826195ad115b56724326aa0d3e91063dd4
[15:02] <seb128> larsu, ochosi said it applies to our theme and should fix it
[15:02] <Laney> I am copying ochosi's patch into a branch already
[15:03] <larsu> awesome, thanks Laney
[15:03] <seb128> Laney, thanks :-)
[15:03] <larsu> and thanks seb128 :)
[15:03] <seb128> yw!
[15:03] <larsu> having a look at the MR you linked as well
[15:03] <seb128> larsu, just in case you missed it, ... thanks ;-)
[15:03] <larsu> also I figured out the gedit squiggly line problem
[15:03] <seb128> no hurry, should be easy enough to review (I think)
[15:03] <seb128> just want another sanity check
[15:03] <seb128> oh, great!
[15:04] <larsu> trying to fix in gtk, but maybe we don't need that
[15:04] <seb128> if that's a theme one maybe sync with Laney to include the fixes in the same landing
[15:04] <larsu> changing the color to a literal one is enough (i.e., don't use @color_name)
[15:04] <larsu> will do
[15:04] <seb128> thanks
[15:04] <larsu> there's still a problem with the underline not being drawn properly when it's on the last lin
[15:05] <larsu> but with the ubuntu font
[15:05] <larsu> not sure what's going on there and haven't been able to find the issue
[15:05] <seb128> is it not displayed at all?
[15:05] <seb128> or like cut?
[15:06] <larsu> cut. Only one row or pixels
[15:06] <larsu> resizing the window or pressing enter to add a new line makes it work
[15:06] <seb128> hum, k, well at least it's better than not displayed at all :-)
[15:06] <larsu> definitely
[15:06] <seb128> don't spend too much effort on it I would say
[15:06] <larsu> agreed
[15:07] <ochosi> btw, i would be surprised if my patch would have any regressions in unity, it should actually "just work"(TM)
[15:10] <mardy> Laney: I'll have a look at it tomorrow, thanks
[15:10] <Laney> thanks to you!
[15:10] <larsu> seb128: ugh, that patch is really ugly :/
[15:10] <seb128> larsu, the theme one from ochosi?
[15:11] <larsu> no, the bluetooth switch one
[15:11] <seb128> larsu, oh, the control center one
[15:11] <seb128> yeah, sorry
[15:11] <seb128> larsu, do you have a better idea/suggestion? ;-)
[15:12] <larsu> seb128: I remember fixing it in my bz5 branch
[15:12] <larsu> not sure though...
[15:13] <larsu> basically, gtkswitch has a way of handling stuff like this
[15:13] <larsu> it's a bit hard to use, but at least you don't need to block signals
[15:13] <larsu> that said, I'm fine adding it downstream for V and fixing it with the bz5 update
[15:13] <larsu> it will work fine from the looks of it
[15:13] <larsu> just wouldn't want it in the actual code
[15:15] <flexiondotorg> ochosi, larsu seb128 I'm very interested in this CSD conversation.
[15:15] <flexiondotorg> Are you planning to add the require patch to GTK3 in vivid?
[15:16] <seb128> larsu, basically you said "not nice but should do the job, we should get it in vivid"?
[15:16] <larsu> seb128: ya. sorry for rambling :)
[15:16] <ochosi> flexiondotorg: the patches are specific to the ubuntu themes, so unless you use Ambiance or Radiance, you'll likely not be affected/interested
[15:16] <seb128> larsu, no worry, thanks for the review ;-)
[15:16]  * larsu will get seb128 to write executive summaries for him from now on :P
[15:17] <flexiondotorg> ochosi, I have forks of Ambiance and Radiance call Ambiant-MATE and Radiant-MATE.
[15:17] <larsu> ochosi: I think flexiondotorg means the patches for the non-composited case
[15:17] <larsu> oh, interesting
[15:17] <ochosi> oh, those ones
[15:17] <flexiondotorg> ochosi, So, I'll be keen add update them with the required fixes.
[15:17] <ochosi> well those patches need theme changes too fwiw
[15:17] <larsu> seb128: I'll comment on the MR
[15:17] <flexiondotorg> larsu, Where is the MR?
[15:17] <ochosi> but i already prepared them locally for our themes
[15:18] <flexiondotorg> ochosi, Is there a bug I can subscribe to for this?
[15:18] <larsu> flexiondotorg: unrelated.
[15:18] <flexiondotorg> k
[15:19] <seb128> larsu, thanks
[15:20] <flexiondotorg> ochosi, Do you have a diff for the changes you made to Ambiance and Radiance?
[15:22] <ochosi> flexiondotorg: it really depends on what CSD related things you're referring to now. the most recent conversation was about gtk3 menus not having shadows, so i pointed to a commit that fixes that. i haven't submitted any changes for the other stuff (CSD without compositor)
[15:22] <flexiondotorg> ochosi, OK, so the menus not having shadows is fixed with - https://github.com/shimmerproject/Greybird/commit/b9f9b0826195ad115b56724326aa0d3e91063dd4
[16:09]  * qengho is afk a bit.
[16:11] <didrocks> pitti: hum, I wanted to avoid merging the 2 to have a clearer view for you about what changed
[16:12] <didrocks> pitti: but as you wish :)
[16:12] <didrocks> pitti: tell me once you rebased the ubuntu branch on top of it and I'll work on the autopkgtests
[16:16] <pitti> didrocks: ah, you don't have a sid VM?
[16:16] <didrocks> pitti: no off hand
[16:16] <didrocks> not*
[16:16] <pitti> didrocks: can do, but I don't plan an upload just for this as it's no effective change
[16:16] <didrocks> pitti: well, it is
[16:16] <pitti> oh?
[16:17] <didrocks> pitti: as stated in the patch, now fsck talks directly to systemd-fsckd
[16:17] <didrocks> I've merged the changes that were planned with latest discussion in the ML
[16:17] <pitti> ah
[16:17] <didrocks> so there is a workflow changes
[16:17] <didrocks> (I tried to be explicit about that in the commit message and in changelog, not enough apparently, sorry)
[16:18] <didrocks> so the sooner would be the better to avoid last minute accident if any
[16:18] <didrocks> (even if I tested heavily a month ago and today)
[16:20] <pitti> didrocks: rebasing now
[16:37] <Trevinho> Mirv: hey, I've just fixed tests in https://code.launchpad.net/~3v1n0/libdbusmenu/custom-stock-item-label/+merge/251840 (vivid builds now, check http://s-jenkins.ubuntu-ci:8080/job/libdbusmenu-vivid-amd64-ci/2/), can you approve the MP?
[16:38] <Laney> Trevinho: Funny, I already did that in silo 27
[16:39] <Laney> want to merge with  lp:~laney/libdbusmenu/libtool-and-gi ?
[16:41] <Trevinho> Laney: ah ok
[16:41] <Laney> then we should be able to add that there
[16:41] <Trevinho> Laney: mh, is ity really needed to call libtool there?
[16:41] <Laney> don't know, but there is a way to keep on doing it
[16:41] <Laney> so why not?
[16:41] <Trevinho> Laney: mh, I've removed it and it's working well...
[16:42] <Trevinho> I'd prefer to remove that, as I don't see the benefit of that
[16:42] <Trevinho> Laney: anyway, I'm merging mine with yours, so we merge both?
[16:43] <Laney> one way is fine, then set it as a pre requisite in the MP
[16:43] <Trevinho> indeed
[16:44]  * willcooke -> EOD
[16:44] <willcooke> o/
[16:45]  * Trevinho Laney: for your love https://code.launchpad.net/~3v1n0/libdbusmenu/custom-stock-item-label/+merge/255709
[16:51] <pitti> didrocks: rebased and pushed
[16:53] <didrocks> pitti: excellent, thanks! will workon that tomorrow
[16:53] <didrocks> work on*
[16:53] <pitti> didrocks: oui, c'est l'heure du dîner .. et de la glace !
[16:53] <didrocks> pitti: un peu tard pour la glace :p
[16:54] <didrocks> (je sais, il n'est jamais trop tard pour une glace ;))
[16:54] <pitti> didrocks: pourquoi ? il y a encore beaucoup du soleil dehors :)
[16:54] <didrocks> pitti: julie est d'accord :-)
[16:54]  * didrocks waves good evening and good glace to everyone!
[16:54] <pitti> didrocks: c'est notre dessert !
[16:54] <pitti> didrocks: and you, à demain !
[16:55] <didrocks> pitti: à demain ;)
[16:56] <Laney> Trevinho: can't approve, I'm going to land my thing and you can do it again once you get someone to do it
[21:07] <robert_ancell> Sweet5hark, how are you testing snaps?