[01:57] http://princessleia.com/journal/?p=8733#comment-12504 [01:58] ^^ andrewsomething willing to help with sponsoring stuff in Debian [02:03] Ah, speaking about mugshot by name. [02:52] Guess I better start being productive again [02:53] :) [02:53] Just got my new laptop [02:53] Likely since you have a sponsor now. Oh? So does it work as well with Xubuntu as they said? [02:53] Time to start a series "Adventures in Installing Ubuntu on a Windows 8 computer" [02:53] Hah, UEFI, have fun! [02:54] Haven't found out yet [02:54] Windows finally finished setting itself up just now [02:54] figured I'd update all that stuff first and move on to the more fun stuff after [05:30] pleia2, Would you be able to point andrew to catfish (in the PAPT) and gthumb? [06:48] Noskcaj: are the RFS or..? [06:49] no official rfs, one is in the PAPT with and IRC topic RFS, the other is on mentors [06:49] PAPT= Python Apps Packaging Team [06:49] ok, thanks [06:49] I know :) [06:49] just checking [06:50] https://lists.alioth.debian.org/pipermail/python-apps-team/2013-November/008393.html ? [06:51] I'll fwd along and Cc: you [06:51] thanks [06:52] Noskcaj: did you create a .deb, or just what is in svn? [06:53] re: catfish [06:53] Just what's in the SVN, but i can make a .deb if you want [06:53] (it builds fine) [06:53] ok, I'll ask andrew what he wants [06:55] :) [06:57] I think you may need to remove the Uploader field in gthumb (pretty sure if that's used the sponsor puts their info there) and it looks like gthumb itself is depending on something in experimental? [06:58] anyway, off this email goes [07:02] I'll check gthumb now [07:04] gthumb has no uploader field. Catfish does so bluesabre can upload too. [07:05] what's in experimental that it b-deps on? [07:07] Noskcaj: I was just looking at http://mentors.debian.net/package/gthumb [07:08] under QA information [07:08] "Maintainer" email is the same as the uploader [07:08] the uploader as in who put it on mentors [07:08] oh :) [07:09] this site has changed a lot since I last looked at it, I should look at it more [07:09] My main issue with gthumb is dpackage-buildflags break it. Although it's not my only package that does that [07:17] hey elfy [07:17] hi Noskcaj [07:20] Does anyone know why autopilot cannot introspect xfce? running "autopilot launch PACKAGE" is proof [07:21] ask lderan :) [07:27] elfy, I did, he has the same problem AFAIK [07:32] autopilot is designed for ubuntu and it's things - no real wonder we have problems [07:35] pretty much my thoughts. I'm also working on transmission, which works, but i don't know how to do half the stuff [07:36] we need to have the discussion about what we need to be trying to get working with it [07:37] I'll get that ball rolling soon, but I'm rather meh about the whole thing [07:38] transmission is good because it's not just xubuntu. My xfce target was screenshooter since it's fairly easy (when autopilot works with xfce) [07:40] yep [07:41] obviously if 'we' have anyone working on autopilot then logically they'd be better working on specific xub things rather than ones ubuntu use as well [07:41] they've got more resources [07:41] but on the other hand - it's not a job [07:42] personally I've not seen or read or heard anything that changes my mind about it [08:57] ali1234: i think we should get all those greeter changes in one branch [09:53] brainwash: ping [10:55] elfy: aye xubuntu specific things would be best, shall see if i can find out why autopilot doesn't like xfce apps [11:08] morning all [11:15] good morning slickymaster :D [11:16] hi lderan, how's everything with you? [11:43] slickymaster: everything is going okay thanks :), how about yourself [11:46] also fine , lderan. Thanks [11:48] huzzah [14:43] ali1234: I've cloned your lightdm branch and applied the xsetroot patch, also compiled your xfwm4 git version.. zooming does work, everything else does not really work: 1) grey background without xfdesktop 2) with xfdesktop the background does not get repainted and will end up grey 3) scrambled screen after unlocking the screen [14:45] ali1234: and zooming is not triggered while being on the desktop, it switches the workspaces, so something needs to be done here to make it more consistent [14:47] ochosi: yeah, I'm slacking a bit and will try to test everything now [14:48] ochosi: the xsetroot change could be merged into ali1234's lightdm branch, if there is nothing wrong with it [14:56] forgot to mention that my screen stays blanked after locking it with light-locker (experimental lightdm branch) [15:49] knome: whenever you'll manage to find the time in your hellish agenda https://code.launchpad.net/~slickymaster/xubuntu-docs/xubuntu-docs/+merge/196213 [15:50] slickymaster, yeah, i need to get that done... i'll be back later today, if you are around, ping me again [15:50] (going to a concert soon, back after that) [15:50] today it will be difficult. Dinner at in laws [15:50] heh, np [15:50] i'll try to do it anyway [15:51] I'll ping tomorrow on that [15:51] we're also looking to get access for more people to the core docs (to be able to merge) [15:51] so that should clear that bottleneck [15:51] brainwash: well, if it doesn't work, it's not working :) [15:52] it would take some load off your back, at least [15:52] sure, and it doesn't hurt to have >1 person able to do any task, since it happens that people are away when they are needed [15:53] ochosi: just a quick one. I think you're right, regarding the Parole's shortcuts. seek is better than skip [15:53] knome: agreed [15:53] slickymaster: ok, sweet, then let's change that and then i'll copy things over to docs.xfce [15:54] ochosi: I'll do it now, and I'll ping once it's done [15:54] in an ideal world with a team our size we should have 3 people able to do things imo [15:55] slickymaster: thanks! [15:56] delegation is many times a key process in organizations [15:56] task delegation ^^ [15:56] elfy, in an ideal world our team size should be bigger;) [15:56] not necessarily much, but it wouldn't hurt to have more active contributors [15:57] well yea - but it isn't so we should be able to multitask [15:57] agreed [15:57] active in the sense that they are more or less self-guided in starting new tasks [16:00] having clear routes (incl. -qa team) to more active contributing (-team membership) is a good thing as well [16:00] anyway, i'm off [16:00] talk to you all later [16:00] cya [16:01] ochosi: my branch already has all the needed changes [16:02] ali1234: hm, do you see any benefit in bluesabre's gtk_image branch anymore? [16:03] not really [16:03] knome: cheerio [16:04] ali1234: ok, i'll try to test it today [16:04] what do you think wrt nick's reply on the xfce-dev ml? [16:12] ochosi, http://smdavis.us/doku/doku.php?id=usage&#keyboard_shortcuts It's done all the occurrences of skip were replaced by seek. You can now copy it to docs.xfce.org [16:14] slickymaster: thanks! will do [16:15] brainwash: you don't need to apply any patch on lightdm [16:15] ali1234: ok, just applied the patch you linked to on the xfce-dev ml for xfwm4 and used your greeter-branch, but that didn't do the trick yet [16:15] ochosi: np [16:15] ochosi: you don't need to apply any patch :/ [16:15] ali1234: i thought for xfwm4 i do..? [16:16] also you can't "make install" lightdm-gtk-greeter [16:16] i will write instructions on how to test it [16:16] wait........ [16:17] ok, great [16:20] slickymaster: perfect, done! [16:20] ochosi: thanks [16:20] well, thank you again ;) [16:21] http://paste.ubuntu.com/6474531/ [16:23] ali1234: hm, what's the difference between the first half and installing the greeter? [16:25] ali1234: also, i've just used the last commit of the zoom2 branch on xfwm4 from upstream, so that should be the same as your branch (minus the zooming) [16:25] if you install the greeter with make install it goes into /usr/local [16:25] yeah, but i used "--prefix=/usr" [16:25] lightdm won't use it's .desktop, it will continue using the old one from /usr/share [16:25] so it won't launch the new greeter you just built [16:25] well with the prefix it does [16:25] if uyou build with --prefix=/usr then it will attempt to load configuration from /usr/etc/lightdm and that will also mess it up [16:25] i know cause i don't have my greeter.conf file anymore and the ambiance theme now :) [16:26] hm [16:26] actually, you should build it with --prefix=/ [16:27] hm [16:27] strange, it always seemed to work fine here this way [16:27] but anyway, i can try it your way, there's not really any problem with that [16:31] http://paste.ubuntu.com/6474559/ [16:31] ok, rebuilding the greeter now then [16:33] rebooting... [16:35] ali1234: what xfdesktop version were/are you using? [16:35] (asking cause it's not working yet, i still get a grey pixmap) [16:35] the one from the repositories [16:35] hm, i'm using the one from the xfce4.12 PPA [16:36] which is xfdesktop4.11.1 [16:36] although that should have no effect on the grey background that xfwm4 produces [16:36] at least that one should be gone [16:36] the grey background happens because xfdesktop has not yet started [16:37] i thought xfwm4 would hold the background "in the meantime"? [16:37] it's supposed to [16:37] :/ [16:37] to be honest, i think you're doing it wrong [16:37] well this time i followed your instructions [16:37] make sure you check out the correct branch [16:38] yeah, zoom2 branch [16:38] and make sure you actually do reboot the computer because just logging out may not restart the greeter [16:38] (i can zoom with xfwm4 now, so it's the right branch) [16:38] yeah, rebooted [16:38] even turned off auto-login ;) [16:39] i mean i agree, usually the user is at fault, but i'm not sure where the mistake could be [16:40] check the source code [16:40] what revision of lightdm-gtk-greeter are you using? [16:41] and what commit hash on xfwm4? [16:42] git branch > * zoom2 [16:43] git pull [16:43] Already up-to-date. [16:45] bzr pull [16:45] Using saved parent location: bzr+ssh://bazaar.launchpad.net/~a-j-buxton/lightdm-gtk-greeter/experimental/ [16:45] No revisions or tags to pull. [16:46] so what revision is on top of your local tree? [16:46] fwiw, with your method of launching the greeter my original greeter.conf seems to be used again [16:46] yeah thats the idea [16:47] ok [16:48] for the greeter: revno: 151 [16:48] timestamp: Sat 2013-11-23 22:29:32 +0000 (Fix the rest of the pixmap leaks.) [16:51] for xfwm4 it's commit b7baa7aa60cdb80759e0872d0ab5a7cb59ec5c10 [16:51] ali1234: ^ [16:51] gotta go now, but i'll be back in an hour or so [17:02] ok the reason it doesn't work is because the zoom2 branch doesn't build [17:02] and apparently neither of you noticed this before running "sudo make install" [17:03] so i must have forgot to commit a file or something [17:05] hmm [17:10] cya [17:11] ok something is very broken here [17:12] HAVE_RANDR has different values in different parts of the code [17:15] i see... xfwm4 has a missing build-dep on libdrm-dev [18:21] right, the new xfdesktop also throws up a grey pixmap for no reason [18:48] ali1234: :/ [18:48] so we also need an xfdesktop patch? [18:48] well the xfdesktop code is crap [18:48] it needed fixing anyway [18:49] it's not really any better or worse now [18:49] it's just broken in a different way [18:49] if you build against tag xfdesktop-4.10.1 then it works, btw [18:49] now bisecting to figure out exactly what the problem is [18:50] xfdesktop is one of the more ancient parts of xfce [18:50] wasn't properly maintained for years, iirc [18:50] and eric did some cleanup, but not a rewrite or anything [18:50] yeah, it looks like someone decided to "tody it all up" [18:51] thing is, nobody cares enough about the desktop [18:51] and it might become an extension of thunar in gtk3 [18:51] whatevs [18:52] what are we gonna do about the gnome CSD? [18:52] not sure, what can we? [18:52] i haven't seen a CSD app in xfce so far [18:52] https://plus.google.com/106778988568562417860/posts/TFYPgcfmj9N [18:52] calculator, unfortunately [18:53] if it was up to me i'd say "drop it, find a new calculator" [18:53] meh [18:53] yeah, the calculator should be replaceable [18:53] but in general, that blows [18:54] well, actually, i'd say "patch gnome calculator to drop CSD and let gnome deal with it" [18:54] the apps should send a request for an undecorated window [18:54] that's possible, xfce4-notes does that [18:54] no, the app shouldn't have CSD [18:54] but in general i agree, a runtime check would be best... [18:54] anyway, it looks ridiculous [18:55] with two decorations and a meaningless appmenu [18:55] actually, we could switch to mate's calculator [18:56] is it in the repos yet? [18:57] it's a bit like forking the current calculator without having to maintain it :) [18:57] i guess not [19:00] anyway, thanks for the hint to that g+ post [19:08] dinner-time, bbabl [19:21] 9becad1569798894bdae9beaffc9076338fed299 is the commit that causes the grey screen from xfdesktop [19:30] i love the commit message on that [19:31] Noskcaj: can you follow up with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711827 ? [19:31] Debian bug 711827 in wnpp "RFA: gthumb -- image viewer and browser" [Normal,Open] [19:31] pleia2, did that last week [19:32] Noskcaj: might want to update the bug :) andrew is still under the impression that it's pending [19:37] done [19:51] ochosi: so... the white flicker now comes from xfdesktop and is completely unrelated to the one i've just fixed [19:51] in fact you'd see grey, then white without my patches [19:57] lderan, wha? :) [20:10] knome, hmm? to your wha? [20:10] :P [20:20] knome, ah it was just a cheerio when you said you're off [20:43] :( [20:58] D: [20:58] this code is horrible [20:59] quit looking at my github repo [21:26] ali1234: new round of compiling and testing, now only xfdesktop shows a white screen for a brief moment [21:26] yeah i'm tryig to fix it [21:26] screen is still scrambled after unlocking via light-locker [21:26] what has happened is that now xfdesktop supports a background per workspace [21:27] so they made it load the background async [21:27] so it doesn't get loaded when the window first opens [21:27] g_signals everywhere... impossible to figure out what order any of this code runs in [21:28] first a grey screen flicker, now a white one :D [21:28] but what about the scrambled screen? [21:28] it wasn't there before, started to show with your experimental lightdm greeter branch [21:29] quite possibly [21:29] amd restricted driver [21:29] the code is all leaky as hell [21:29] i removed the leaks from lightdm [21:29] but there's still the leaks in xfwm and xfdesktop to deal with [21:30] i need to deal with xfdesktop first, because it also plays around with the root window atoms, but in a none-standard way (while the comments complain about the lack of a standard) [21:30] it started as small screen flicker issue.. now it's a huge code mess up [21:31] the two flickers are totally unrelated [21:31] yeah [21:31] but we don't want to have additional ones [21:31] yeah what i mean is one doesn't cause the other [21:31] without my patches you see grey then white [21:31] I understand this [21:31] it's just very hard to notice [21:32] can you triage bug 1251431 ? [21:32] bug 1251431 in LightDM GTK+ Greeter "user background gets painted over background specified in config file" [Undecided,New] https://launchpad.net/bugs/1251431 [21:33] please :P [21:35] there you go :) [21:36] thanks :) [21:37] what do you see if you kill xfdesktop btw? [21:39] a white screen, then my user background [21:40] what do you see before the white screen? [21:40] xfdesktop gets restored by xfce4-session [21:40] it should be whatever is in the xfwm4 root tile [21:40] this might be your background (you can tell because icons disappear) [21:40] or it might be the grey [21:41] It's grey, I've done it before. [21:41] if you change wallpaper in xfce, the root tile shouldn't update [21:41] Unit193: yeah but with my patched stuff? [21:41] No, stock. [21:41] there are three different things that show the background [21:41] ali1234: yeah, i can see the root background [21:41] (if i insist on killing xfdesktop enough) [21:41] right, it's the user wallpaper [21:42] lightdm greeter sets it in the real X11 root window pixmap, xfwm has it's root tile, and xfdesktop then draws it in a window too [21:42] so, your xfwm4 patch works [21:42] yeah, ideally there'd be only one or two of those :) [21:42] I killed xfdesktop like 3 times within a small time frame and now it does not get restored anymore =S [21:42] xfdesktop also copies it to the x11 root window, but at this point you can't see that any more without killing xfwm4 [21:42] brainwash: 5 times and then it dies [21:43] oh [21:43] just run it again [21:43] yeah, so it's the expected behavior? [21:43] 5 is the lucky number :) [21:43] yes [21:43] ok [21:44] ochosi: only lightdm-greeter patch i am totally happy with - all the others still have problems, leaks, and dangling pointers [21:45] ali1234: i hope we can merge that part soon [21:45] Five is right out :0 [21:45] but i'd prefer to wait until the rest of this is kinda settled [21:45] i don't know why it causes corruption in light-locker, but it is probably something to do with the memory leaks being fixed [21:46] actually this has nothing to do with light-locker, lightdm handles the switch-to-greeter/lock stuff [21:46] what actually happens when light-locker starts the greeter in locked mode? [21:46] on the light-locker side, it puts a fullscreen window over your session on VT7 and switches to the greeter [21:47] the greeter itself is started as always [21:47] on VT8 [21:47] so the locker is then running in a different X server? [21:47] you can also try all this without light-locker, just use dm-tool (uses different signals though) [21:47] well, yes and no, the *session* is still runnning in a different X server [21:47] sry, gotta quickly run, be back in 20min [21:48] the session carries on running in vt7 [21:48] yup [21:48] but the "locked" display is on VT8, which is a totally different X server [21:48] yup [21:48] in that case, i don't see how the corruption can be my fault :) [21:48] that's lightdm's design [21:48] brb [21:49] it has to be a X server bug [21:49] dm-tool lock works kinda [21:50] desktop is black and can be restored by moving a window [21:50] light-locker corrupts the screen [21:51] it works on intel and nvidia [21:54] ah right [21:54] I did not restore xfdesktop [21:54] that shouldn't matter [21:55] without it I get a black screen after unlocking [21:56] and by moving a window I can force it to redraw the background [21:56] yeah, there won't be any redraw events on the root tile [21:57] sill an issue if some people disable xfdesktop or? [21:57] still [21:58] kind of, but there's not much can be done about it [21:58] force a redraw via light-locker? [21:59] yeah, you'd have to. this is a unrelated issue though [21:59] as of now light-locker corrupts the screen [21:59] :/ [21:59] which screen? [21:59] do you mean the background behind the unlock dialog? [21:59] the X display server [21:59] there's two X displays involved... [21:59] no, after returning back to vt7 [22:00] ah. ok, that's ... something else [22:00] that likely happens because xfdesktop clears out the atoms... really, it would be better if it didn't [22:00] or if it has to, then it should do it properly [22:00] basically a black screen via some colorful pixels [22:01] that might be the vt switch happening [22:01] so many bugs [22:01] it happens with light-locker, not with dm-tool [22:01] well, i don't know what dm-tool does [22:01] light-locker creates this overlay to actually lock vt7 [22:01] yes, but then it switches to vt8 [22:02] dm-tool --help [22:02] right [22:02] everything works until I return back to vt7 [22:02] yeah that doesn't tell me what it actually does... [22:02] so what happens if you press ctrl-alt-f1, then alt-f7? [22:02] mmh, time to take a look at the source code of lightdm :) [22:03] some X servers just display corruption during vt switch [22:03] screen is kinda dead [22:03] there's nothing we can do about that, if that's what it is [22:03] nothing can restore it [22:04] yeah, but it does work with dm-tool, so it's a strange issue [22:04] light-locker works the same, but it actually locks vt7 with an extra overlay [22:05] this overlay might be the cause [22:06] so... i've got an idea [22:06] i need to fix all this xfdesktop root pixmap rubbish [22:09] :( [22:10] so much extra work [22:10] well i can't leave it unfixed [22:12] hmm... another idea... maybe we can set the desktop window hidden until the background loads [22:13] you could even let it fade in ;) [22:13] I have no clue, this whole thing is getting more complicated the more we.. the more you try to fix it :) [22:14] ochosi: but the idea is it's same as what's already there anyway... [22:19] ali1234: that's the idea, but only on ubuntu [22:20] in no other distro does xfdesktop inform accountsservice of the user's background [22:20] so the greeter cannot know about that and will show the same background every time (defined in /etc/lightdm/lightdm-gtk-greeter.conf) [22:21] hmm [22:21] in fact, accountsservice was patched in ubuntu to support the user-wallpaper [22:21] this is lame [22:21] that is why it's an ubuntu-specific patch [22:21] the background loader is trigger by the window being realized [22:21] the window is realized when it becomes visible [22:21] so that's too late..? [22:21] therefore there is no way to load the background withut making the window visible first [22:22] i could force it to be realized with gtk_widget_realize [22:22] well if xfdesktop would show the root background first, that would help [22:23] even if it only were xfwm4's background [22:23] that's exactly the problem [22:24] wow, that actually worked [22:24] ? [22:24] instead of gtk_widget_show(desktop), gtk_widget_realize(desktop) [22:24] then later, *after* the background loads, gtk_widget_show(desktop) [22:24] right [22:25] works perfectly, apparently [22:25] sweet [22:25] wanna post the patch so i can quickly give it a spin? [22:25] (i still have everything else in place, so i'd hope it'd fix everything) [22:25] sure... but expect it to be buggy [22:28] http://paste.ubuntu.com/6476175/ [22:29] there is still the issue of the background pixmap usage in xfwm4 and xfdesktop, so you might still get screen corruption [22:29] but the login should be seamless [22:30] also if you have a solid colour background is might never get shown [22:30] wow, quite a minimal patch :) [22:32] they always are [22:32]