=== tmpRAOF is now known as RAOF === tmpRAOF is now known as RAOF [03:45] RAOF, do you know any history behind DRI3 and xserver-xorg-video-intel? [03:48] robert_ancell: You mean - why we've disabled it? [03:48] RAOF, yeah. Well, not enabled it (it is disabled by default) [03:48] robert_ancell: I didn't follow closely, but it caused bugs. [03:48] That was my assumption - just not ready for prime time. [03:48] RAOF, do you know which clients make use of it? [03:49] Mesa [03:50] RAOF, do you know if anyone is shipping with it enabled yet? [03:50] Nope. [03:50] Maarten would be your man there. [03:51] RAOF, cool, thanks for the info [04:00] RAOF, hmm, I enabled DRI3 and nothing blew up. Any way of confirming that it's actually being used and not DRI2? [04:04] Xorg.0.log should say something about DRI3 [04:04] For 100% confirmation I think you could try xtrace? [04:07] RAOF, bingo. xtrace for the win [04:08] 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] No idea, sorry. [05:47] good morning === thumper is now known as thumper-afk [06:11] Good morning [06:14] hey pitti [06:17] bonjour didrocks ! [07:14] bonjour! [07:17] pitti: still having some hope on the systemd fsckd thing? Seems like last email was pretty clear… [07:17] didrocks: from Kay? yeah :/ [07:17] bonjour larsu! [07:17] pitti: I guess the best course of action is to rationalize our patch with the additional fixes (all that in one patch) [07:17] didrocks: so it seems we'll have to move fsckd to the Debian branch then [07:17] morgen pitti! Wie geht's? [07:17] and apply it against v219 [07:18] pitti: I can do the first draft, then, you can review? [07:18] didrocks: yeah; I hope that we don't have to patch s-fsck so much but that this can stay [07:18] didrocks: sure! [07:18] pitti: let's see what the diff would be (it's mostly removals in s-fsck) [07:18] didrocks: btw, I tried with the fsck mock on my laptop yesterday, and I didn't see any progress :/ [07:19] didrocks: it's not the "fixes from trunk" which I added yesterday, happens with either [07:19] pitti: at boot? [07:19] yes [07:19] weird [07:19] (with real plymouth) [07:19] I only saw the "Ctrl-C" message [07:19] was working 2 days again with a real fsck here [07:19] ago* [07:19] hum [07:19] ah, good [07:19] well, I don't know what I messed up, at some point I need to reinstall my laptop [07:20] pitti: anyway, with the rationalized patch, I'll give some try… [07:20] didrocks: maintaining the translations will be the most ugly part, I figure [07:20] yeah [07:20] not sure what we can do here… [07:20] (already keeping that in a separate patch maybe?) [07:23] didrocks: what did we do in the plymouth themes? were these translatable at all? [07:23] didrocks: but yes, separate patch for those sounds better [07:24] pitti: our plymouth themes are .script files [07:24] pitti: no i18n support [07:24] that's why in addition to the machine parsable data, we send the l10n strings [07:26] didrocks: right; I meant it wouldn't be too much of a regression if we would drop them in the future [07:26] although it'd be a shame [07:26] pitti: yeah, that's a possibility, but still a regression from the user POV [07:26] pitti: should we revert to "c" btw? [07:26] for cancelling [07:26] as we did in the past [07:26] as upstream doesn't care anymore, this change is now useless [07:27] hey didrocks larsu pitti [07:27] (shame for ctrl+c, took some time to figure out how the protocole handled it specially… as it was requested upstream) [07:27] re seb128 [07:31] didrocks: I don't mind much TBH; if you want to switch back to C, please do [07:32] pitti: ok, I'll try to handle this [07:32] pitti: on the cancel only showing, it was with our ubuntu theme, right, not a debian one? [07:33] (in that case, it's normal that you didn't get any progress) [07:33] o/ [07:33] hey willcooke [07:34] didrocks: right, standard vivid desktop [07:36] hey willcooke [07:43] seb128q, hey [07:44] ??? [07:45] seb128 greets his alter-ego [07:45] willcooke: he's broken [07:46] need to reboot him [07:46] morning willcooke :) [07:46] lol [07:46] Hey folks. :) [07:46] didrocks: can you reach the power button from where you are? [07:46] hi TheMuso! [07:46] larsu: pushing it for 5s right now [07:46] larsu, trying to reproduce that "notify-osd notification doesn't go away" people reported [07:46] seems it's quassel irc users [07:46] didrocks: lol [07:46] seb128: oh? [07:47] * larsu mumbles something about dreading to look at that code base again [07:48] hey TheMuso [07:52] larsu, you are safe [07:52] $ dbus-monitor interface=org.freedesktop.Notifications | grep quassel [07:52] string "quassel" [07:52] variant string "quassel" [07:52] string "quassel" [07:52] variant string "quassel" [07:52] string "quassel" [07:52] variant string "quassel" [07:52] quassel sends notifications several time a second for ever [07:52] seb128: quassel quassels too much [07:53] seems so [07:53] (quassel is chatting in German) [07:53] but you knew that ;) [07:53] :-) [07:54] cyphermox, ^ just a fyi, your notify-osd issue from the other day, it's a quassel bug [08:02] cyphermox, https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1442005 [08:02] Ubuntu bug 1442005 in quassel (Ubuntu) "Notifications are shown forever" [Undecided,New] [08:04] g'night TheMuso [08:05] willcooke: Later. :) [08:05] pitti: keeping debian/patches/Add-gettext-support.patch separated for now, unsure if they are not going to keep it [08:06] didrocks: yes, sounds good [08:06] hey ho [08:06] hey Laney, how are you? [08:06] morning Laney [08:06] feeling alright thanks pitti [08:06] although! [08:07] I went to donate blood last night and got denied because my iron was too low [08:07] and the shocking thing is that the person suggested this may be because I drink too much tea [08:07] which apparently affects iron absorption [08:08] hey didrocks [08:08] what's up? [08:08] Laney: oh, wow [08:08] Laney: weren't you in that program to test whether the interval between donations could be reduced? [08:08] didrocks, pitti, https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1441883 might be something for you? [08:08] Ubuntu bug 1441883 in lightdm (Ubuntu) "15.04 Vivid Vervet won't boot after uninstalling lightdm" [Undecided,New] [08:09] Laney, hey [08:09] seb128: boot bugs? go away! :-) [08:09] lol [08:09] j/k, /me looks [08:09] "Failed to isolate default target, freezing." [08:09] pitti, danke [08:10] pitti: indeed, so could also be related to going more frequently [08:10] Laney, time for coffee man: [08:10] ah, probably some fallout from the /e/X/default-display-manger handling [08:10] but they'll only have an idea of that when looking at the whole dataset I suppose [08:10] Laney: yeah, I had trouble keeping up my iron even with 3 month intervals [08:10] 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] lol [08:13] pitti: deleting lightdm should empty /e/X/d-d-m, right? [08:13] didrocks: ideally yes; I'll try to reproduce this in a bit [08:14] 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] I figure it's trying to start display-manager.service and fails [08:16] pitti: it's Wants=display-manager.service [08:16] though [08:17] ah [08:17] pitti: I think I get it [08:17] it's the failsafe mode [08:17] Requires=display-manager.service [08:17] OnFailure=failsafe-graphical.target [08:17] (for graphical target) [08:17] I wonder how we can make this elegant [08:18] as the main point is "you wanted to have a graphical system (graphical.target), no graphics -> failsafe" [08:21] didrocks: hm, perhaps some Condition? could we make it ConditionFileNotEmpty=/e/X/d-d-dm or so? [08:21] didrocks: oh, d-d-m still has lightdm even after purging [08:23] pitti: ok, so double issue :p [08:23] pitti: ConditionFileNotEmpty? you can't express that to tell "only fallback if file not empty" [08:24] it will not executed graphical.target is /e/X/d-d-m empty [08:24] which is the default target, so I guess it will fail and trigger failsafe as well, no? [08:26] 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] (I have some trouble understanding what you meant to say, sorry) [08:27] didrocks: how is the fallback implemented right now, OOI? perhaps we did that wrong? [08:27] pitti: shouldn't then multi-users.target be the default, rather? [08:27] pitti: so, graphical.target Requires=display-manager.service/OnFailure=failsafe-graphical.target [08:27] it feels like display-manager.service should have something like OnFailure=ourfallback.service ? [08:28] 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] pitti: not sure we can extends display-manager.service though, it needs a try [08:28] didrocks: oh, requires; I thought it's wants [08:28] as display-manager.service is in /etc [08:28] and our extension for OnFailure would be in /lib [08:29] let me give it a try [08:29] didrocks: that should work [08:29] systemctl cat display-manager.service [08:29] # /lib/systemd/system/lightdm.service [08:29] didrocks: ah right, cat resolves symlinks [08:29] pitti: let me give it a try [08:31] pitti: seems to work [08:31] so, /lib/systemd/system/display-manager.service.d/xdiagnose.conf containing OnFailure=failsafe-graphical.target [08:31] and this extends the Alias display-manager.service, in /etc [08:32] pitti: I'll handle the failsafe part of the bug, but /e/X/d-d-m needs to be empty still [08:32] I guess [08:32] didrocks: ok, I can handle that part [08:32] * didrocks stops his systemd/fsckd rebasing [08:33] 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] didrocks: nah, don't interrupt stuff, it's not *that* urgent [08:33] pitti: well, I'm in that context [08:33] pitti: display-manager.service will exist, by the generator [08:34] hum, or maybe not [08:34] one sec [08:34] needs to check, I guess I check for the unit [08:34] didrocks: the boot fails because it doesn't exist :) [08:34] didrocks: I added an xdiagnose task with a very short summary [08:34] pitti: yeah, but then, I shouldn't create the symlink [08:34] thx! [08:35] * pitti hugs didrocks, thanks for that (I'm not that familiar with xdiagnose) [08:36] 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] pitti: so, would be better to clean it up, I guess, but not required [09:00] pitti: uploading the fix [09:00] \o/ === vrruiz_ is now known as rvr [09:35] happyaron, hey, are you looking at https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1439202 ? [09:35] Ubuntu bug 1439202 in ibus (Ubuntu) "/usr/lib/ibus/ibus-ui-gtk3:11:XKeysymToKeycode:keybinding_manager_bind:panel_keybinding_manager_bind:panel_bind_switch_shortcut:panel_construct" [High,Confirmed] [09:35] happyaron, it's in the top 5 vivid issues for the week [09:36] cyphermox, https://errors.ubuntu.com/problem/91da1afe1d626059f88ff4a6f225718a2e20ed3d ... seems like your fix didn't really fix it? [10:28] seb128: I'm trying to sort out my ticket issue... [10:28] getting some trouble [10:29] that's on the top on my list [10:29] (means the bug) [10:29] will deal with it this night [10:31] Can somebody please sponsor bug #1441629? (The queue is long, and it's soon final freeze.) [10:31] bug 1441629 in fonts-android (Ubuntu) "Change prefix number of symlink 69-droid-sans-fallback.conf to 65" [High,In progress] https://launchpad.net/bugs/1441629 [10:41] hey desktopers :) [10:43] didrocks, hi, would you mind proposing bamf in *debian* to be maintained by pkg-mate? By sending a proposal to "MATE Packaging Team " [10:43] ricotz: sure, can do [10:44] any formal template or free-form is enough? [10:44] didrocks, thanks, no idea if there is a formal process to change owner-ship of an package [10:45] just get someone to upload it and change the maintainer [10:45] sounds easier this way then, ricotz, doing this? ^ [10:45] didrocks, i guess just a few lines regarding the fact isn't updated and outdated [10:45] it is orphaned, they can just do it [10:45] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779565 [10:45] Debian bug 779565 in wnpp "O: bamf -- Window matching library" [Normal,Open] [10:45] yeah, I got it orphaned recently [10:46] didrocks, debian-mate wants some kind of on-the-record statement to not step on someones toes [10:46] unnecessary [10:46] they should just adopt the package [10:47] email sent, if that can make them happy :) [10:47] Laney, didrocks, thanks! [10:47] yw! [10:47] https://www.debian.org/devel/wnpp/#l3 [10:47] * didrocks is all about people feeling confortable [10:48] they should know how the procedures work [10:48] orphaned package -> someone take this [10:49] interesting that mate wants bamf ... [10:49] well, wnck isn't enough for windows matching [10:49] they propbably wants better icons in the status bar :) [10:49] and so matching desktop files [10:50] yes i'm sure they want to do matching with it [10:50] still interesting [10:50] Laney, it is required by plank ;) [10:51] what is that? [10:51] a dock/launcher application [10:52] i see === thumper-afk is now known as thumper === MacSlow is now known as MacSlow|lunch [11:43] pitti: I'm almost done, but I'll do multiple checks first. More complex due to recent trunk changes [11:44] happyaron, thanks === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [12:16] heh [12:16] re-debugging a FTBFS that I fixed in October [12:16] bring back daily landing! [12:21] YEAH \o/ [12:21] * didrocks has some FTBFS issues as well, I wonder if it's not an autotool dep [12:21] what kind? [12:22] i'm just browsing the archive rebuild + fixing stuff [12:24] Laney: I think it's a -j4 issue (and so a dep), I'm rebuilding without it [12:24] it's still this fsckd-out-of-trunk followup [12:24] Laney, what was defined that datadir in g-t and stopped doing so? [12:24] Laney, just to know if we can look for similar cases [12:26] didn't find where it came from [12:26] all the autotools stuff is the same version :( [12:33] * Laney diffs the build deps === pstolowski is now known as pstolowski|lunch [12:42] 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] The system is going down for halt NOW! [12:42] SIGPWR received [12:42] I re-started it, and lxc-ls says is running, but it has no IP [12:43] sca-trusty RUNNING - - - NO [12:43] so I can not ssh into it. Any ideas? [12:45] seb128: aha, intltool [12:47] i'll see if there are more of these [12:48] k [12:48] looks like they didn't consider that intltool.m4 is an interface [12:48] 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] Laney, they = dobey? ;-) [12:49] ^o) [12:50] was in 2013, probably can forgive him [12:50] hehe [12:53] seb128: if you want to look at this stuff, there's a gcc5 test build too [12:53] i'm looking at the normal toolchain one [12:54] Laney, ok, I can have a look to that [12:57] huh? [13:01] dobey, http://launchpadlibrarian.net/202626076/gnome-bluetooth_3.8.2.1-0ubuntu11_3.8.2.1-0ubuntu12.diff.gz [13:02] hmm that's odd [13:03] https://bazaar.launchpad.net/~intltool/intltool/trunk/revision/742 === alan_g|lunch is now known as alan_g [13:07] pitti: hum, I can build successfully with -j1, but can't with -j4… [13:07] 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] linking issue (probably an order thing) [13:08] I wonder why, doesn't seem I changed Makefile.am at all [13:09] pitti: did you get this kind of issues with gpb (like timestamp?) [13:13] * didrocks does a boot test [13:14] dobey: ya, I went for this one but intltoolize would also work [13:14] * Laney goes to lunch [13:22] didrocks: no, I always build with -j4, I never ran into issues [13:22] didrocks: what's the particular output? [13:24] pitti: just that it doesn't find fsckd.o, will paste now that I rebase on experimental in some minutes [13:24] pitti: otherwise, all works well: cancellation (kept Control+C), translations, progress report… [13:25] (with the binaries compiled with -j1) [13:44] pitti: http://paste.ubuntu.com/10782782/ [13:44] pitti: works fine with a clean -j1 though :/ [13:45] as you can see, src/fsckd/fsckd.o builds successfully… [13:47] pitti: oh, I think I got it, fixing… === pstolowski|lunch is now known as pstolowski [13:49] didrocks: hm, that indeed looks like a missing dep somehwere in the makefile? [13:50] pitti: yeah, found and fixed I guess [13:50] rebuilding to ensure [14:12] larsu, back? [14:13] 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] 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] Gnome bug 746222 in .General "Improve CSD windows without a compositor" [Normal,Resolved: fixed] [14:18] ochosi: aye aye, I think larsu was going to check it out [14:19] 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] okeydokey [14:19] feel free to build a test package and do this in advance [14:19] you'll definitely need it at 3.16 time in any case [14:19] larsu, Laney, ochosi, Trevinho, btw, is bug #1441975 a gtk or a theme or a compiz issue? [14:19] bug 1441975 in nautilus (Ubuntu) "have not shadows" [Undecided,Confirmed] https://launchpad.net/bugs/1441975 [14:19] context menus issue [14:20] my money is on compiz [14:20] lol [14:22] i think without compositor, you can't get those shadows [14:22] but theoretically it could also be a theme issue. i wonder though why it would be limited to nautilus then [14:22] it's not [14:22] it just got reported there [14:22] oh, so no shadows underneath any context menus in gtk3? [14:22] right [14:22] works with gtk2 apps though [14:23] seb128: hmmhmh [14:23] then if it's for all gtk3 apps it's likely the theme [14:23] larsu, ^ [14:23] (sorry for the flip-flop :)) [14:23] hehe [14:23] no worry [14:23] seb128: should be gtk theme issue, as gtk3 now does that client side [14:24] lemme test that in xubuntu real quick... [14:24] Trevinho, ochosi, thanks [14:24] yes, definitely a theme issue [14:24] seb128: so, the fact is that we should add client shadows only to menus it seems [14:24] or... We make sure that compiz does that again [14:24] i have shadows there with greybird in gtk3, but not with ambiance [14:24] ochosi: yeah, that's doing it on client side [14:24] i think that is the way to go [14:25] you can really tweak those shadows nicely with css [14:27] if i'm not mistaken, this should be it: https://github.com/shimmerproject/Greybird/commit/b9f9b0826195ad115b56724326aa0d3e91063dd4 [14:28] yup [14:29] that's it, just tested it successfully with ambiance [14:29] seb128: ^ [14:29] also, CSD is quite unusable outside of Unity (or: without compiz) with Ambiance/Radiance [14:29] no shadows, no borders... [14:30] that's a bit sad, other than that, Ambiance works great with Xfce [14:30] ochosi, thanks [14:30] ochosi, is that a theme issue as well? [14:31] but i guess you guys stuck to compiz drawing all those shadows [14:31] yeah [14:31] it is [14:31] Laney, larsu, ^ can you add your list to look at getting something similar to that in our themes for vivid? [14:31] makes sense [14:31] Ambiance: http://i.imgur.com/BZqbCOr.png [14:32] Greybird: http://i.imgur.com/51Sz1SF.png [14:32] rebooting for finale testing [14:32] the difference is a few lines in your gtk-widgets.css [14:33] (plus disabling compiz' shadows for CSD apps i guess) [14:34] ochosi: we can't disable compiz shadows yet [14:34] 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] ochosi: but you can add a css rule only for menus [14:35] pitti: this includes the new workflow that I implemented a month ago (the patch which was never reviewed by upstream…) [14:35] Trevinho: i see. well the commit in greybird i pointed you to does only that, so it's all you really need. [14:35] 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] 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] 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] (phew) [14:38] didrocks, enjoy! [14:38] 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] seb128: enjoy as well :) [14:39] ochosi, :-) [14:39] didrocks, thanks [14:40] didrocks: rebasing> that's ok, I usually do it the other way around (rebasing ubuntu changes on top of experimental) [14:40] didrocks: so landing this in exp only is fine [14:40] mardy: yo, any chance you could take a look at the libsignon-glib build (test) failure in vivid? [14:40] pitti: ok, so mind doing this, then I pull and fix eventual failing autopkgtests? [14:41] 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] 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] ah, that's in 0003 [14:44] I think the removal should be in 0001, and 0003 just the fuzz [14:45] but I can do that [14:48] 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] didrocks: pushed (with 0003 merged into 0001), many thanks! [14:51] mardy: (filed bug, assigned you) [15:00] seb128: ya back for a while but was just having a tea with faina (lots to talk about) [15:00] seb128: the shadow thing is moot if we disable csd on unity, like Trevinho suggested [15:00] larsu, no hurry, enjoy your tea :-) [15:00] done now :) [15:01] larsu, saw the theme change ochosi suggested? [15:01] I've no real opinion on how to fix it, but seems like we should address it for vivid [15:01] 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] no shadows under context menus you mean? [15:02] yes [15:02] ya indeed :) [15:02] well around menus rather [15:02] is there a patch? [15:02] byt yeah [15:02] larsu, https://github.com/shimmerproject/Greybird/commit/b9f9b0826195ad115b56724326aa0d3e91063dd4 [15:02] larsu, ochosi said it applies to our theme and should fix it [15:02] I am copying ochosi's patch into a branch already [15:03] awesome, thanks Laney [15:03] Laney, thanks :-) [15:03] and thanks seb128 :) [15:03] yw! [15:03] having a look at the MR you linked as well [15:03] larsu, just in case you missed it, ... thanks ;-) [15:03] also I figured out the gedit squiggly line problem [15:03] no hurry, should be easy enough to review (I think) === alan_g is now known as alan_g|afk [15:03] just want another sanity check [15:03] oh, great! [15:04]