[09:53] ali1234: so your xfdesktop patch already got merged, i'm starting to feel more optimistic all of this can be figured out in time [10:10] morning all [10:14] Howdy. [10:16] hi Unit193 [10:19] elfy: we're still facing https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1250560. I think that the test should really be rewritten. I can do it if you feel that you already have plenty to deal with [10:19] Ubuntu bug 1250560 in Ubuntu Manual Tests "Use of gksudo/gksu in testcases for Xubuntu Desktop in Trusty Daily " [Undecided,In progress] [10:45] slickymaster: Have you looked at why the one paragraph won't translate by chance? :p [10:46] Unit193: not sure if I understood what you mean. What paragraph and where? [10:48] http://sigma.unit193.net/xubuntu/pt/ the only bit there I can read (English), wasn't sure if it was because the pot file has "the the" where it shouldn't or now. [10:57] Unit193: I think that it might be related to the fact that knome hasn't merged https://code.launchpad.net/~slickymaster/xubuntu-docs/xubuntu-docs/+merge/196213 yet and probably that's causing the pot file not to be updated [10:57] but I could be wrong [10:58] Doesn't really look related. [10:59] Unit193: let me check something [11:03] Unit193: if you go to https://translations.launchpad.net/xubuntu-docs/trusty/+pots/desktop-guide/pt/+translate?batch=10&show=all&search=The+complete+set+of+topics+is+listed+below you'll see that the paragraph still contains the duplication of definite article "the" even though the translation doesn't consider it [11:08] Unit193: but there are several items that continue not to be translated in http://sigma.unit193.net/xubuntu/pt/ [11:21] Ah, I only really noticed that one because it was on the front page and the same across the board. [11:22] Unit193: not sure if it will answer it but as far as I've been able to dig it out, the time stamp on the last Launchpad automatic translations update is from 2013-11-11 05:41:30 UTC [11:28] don't look at me. [11:28] ;) [11:31] * Unit193 glares at knome. [11:39] * slickymaster also [11:46] by the way knome, you ask me to remember you of https://code.launchpad.net/~slickymaster/xubuntu-docs/xubuntu-docs/+merge/196213 [12:02] elfy: FYI https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1255061 [12:02] Ubuntu bug 1255061 in Ubuntu Manual Tests "Instruction error in Xfce4 Keyboard Settings in Xubuntu Desktop for Trusty Daily" [Undecided,In progress] [13:33] ohai [14:14] ochosi: in time for what? [14:20] slickymaster: if you want to go for it and yes I've seen the new bug :) [15:05] elfy: I'm assuming that when you say that if I want to go for it you're referring to https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1250560, so i'll assign myself and later will propose a merge request [15:05] Ubuntu bug 1250560 in Ubuntu Manual Tests "Use of gksudo/gksu in testcases for Xubuntu Desktop in Trusty Daily " [Undecided,In progress] [15:53] ali1234, ochosi: latest version of xfdesktop enables a smooth and flicker-free transition [15:53] yes, my patch was accepted [15:53] BUT the gtk theme for the desktop elements does not get applied on first start [15:53] after killing xfdesktop is looks ok [15:54] hmm [15:54] you mean icons? [15:54] it works for me... [15:54] icon label bakcground, font color and this rectangle to mark icons [15:55] locking via lightdm is still broken [15:55] screen corruption [15:55] i'm going to mak a test program that dumps the atoms and pixmaps [15:56] there is really no reason for the screen to be corrupt from these patches [15:58] another relog and once again the desktop element are not themed correctly [15:58] no hint in the x session log [15:59] restarting xfdesktop fixes this, so I'll have to redirect the error output of xfdesktop [16:07] http://en.zimagez.com/zimage/onetwo.php [16:07] left ok, right bad [16:08] that is really strange [16:08] and this doesn't happen without the patch? [16:09] it happened occasionally before with xfdesktop 4.11 [16:09] now everytime [16:10] well, not really related, I'll file a report and try to get some log information [16:12] when all else fails, because the output gets redirected, i just throw in a system("logger foo"); [16:16] ali1234: in time for 14.04 [16:17] brainwash: you can try to clear you session cache [16:17] settings-manager > sessions and startup >... [16:21] .. > session > clear saved sessions [16:21] and check whether you have odd stuff in your autostarted apps [16:21] brainwash: ^ [16:23] yeah, session cache is cleared on every reboot/relog on this system [16:24] ali1234: so it does work properly if I start xfdesktop manually after login [16:24] looks like some sort of race condition then [16:27] added a delay before xfdesktop launches -> looks ok [16:27] again, there's already loads of delay on xfdesktop... [16:28] it's a slow system with a damn slow hdd [16:29] and adding this extra delay fixes it for me [16:29] now the desktop elements are properly themed every time I login [16:31] maybe it's reproducible if you delay the launch of xfwm4 [16:31] i doubt it [16:31] xfdesktop waits for xfwm4 to start [16:32] you could try increasing the amount of time it waits (it waits for 5 seconds normally) [16:32] on my system it always waits for the full 5 seconds [16:32] I've delayed the launch of xfdesktop by 1 sec [16:33] 1 sec makes a difference on this system [16:34] hm, i gotta test it but it seems like the experimental branch of the greeter really breaks locking/suspend-wakup [16:34] yes, it does for me too [16:34] as you described it, black/blank screen [16:35] i'll try it again a little later and then kill light-locker [16:35] no visible pixels? [16:35] that should usually unlock the session, if light-locker were the culprit [16:35] no [16:35] I see a black screen with some pixels [16:35] what graphics driver are you using again? [16:35] the gpu is kinda dead at this point I assume [16:36] amd hd5670, restricted driver [16:36] hm, i see [16:36] so I am forced to reboot [16:36] nah, you can also go to a tty and run "sudo service lightdm restart" [16:36] at least i can [16:36] does not work [16:37] gpu dead/stuck [16:37] that's odd [16:37] it is [16:37] xscreensaver to the rescue! :) [16:38] it happens with the experimental branch [16:39] the greeter from trunk works for you? [16:40] it does [16:40] it used too [16:50] i thnk this is xfwm4 problem... [16:52] bbiab [17:03] ali1234: so lightdm screen locking works ok for you? [17:44] lderan: if you're about later can you ping me :) [17:45] slickymaster: yep - you got it right :) === G4MBY is now known as PaulW2U [17:46] brainwash: yes, works fine [17:46] nvidia and intel [17:47] brainwash: try xfwm4 trunk [17:49] bbl [17:58] pleia2: so i assume the guys you contacted about their wallpaper submissions missing a license never got back to you..? [17:58] ochosi: nope [17:59] hm, right [17:59] drop them [17:59] they can resend if they care enough [17:59] if they don't reply to emails, i suppose they don't care enough though [17:59] hm yeah, i was thinking about dropping them as i was cleaning up the submissions page again [18:00] but i think if i do that, i'll also put more verbose text on the submissions page about the acceptance procedure and how ppl can know why their stuff was dropped (wiki history) [18:00] ochosi, the next time you move stuff, can you add a

or sth? (----) [18:00] knome: you mean for you to know which ones are new? [18:00] yep [18:00] sure [18:01] i can tell you now if you wan [18:01] t [18:01] isn't "water" against the guidelines? (people) [18:01] traslasierra -> are new [18:01] traslasierra downwards [18:01] but yeah, would be easier to have a mark so you could batch-move and i wouldn't have to remember :) [18:01] we also accepted the walking fisherman [18:01] yeah, will do from now on [18:01] and the diver [18:02] and the "as the two palms watch" [18:02] heh. [18:02] i'd say as long as it's only a silhouette it's not as bad [18:02] * elfy lost the link to this wallpaper stuff :| [18:02] https://wiki.ubuntu.com/Xubuntu/Roadmap/Specifications/Trusty/CommunityWallpapers/Submissions [18:02] elfy: ^ [18:03] there's also the link to the accepted ones [18:04] some nice ones there indeed :) [18:04] yeah [18:05] it's starting too look good [18:05] oops. [18:05] * elfy likes 'watery' ones ;) [18:06] ok, thumbs (are) up [18:07] thanks knome [18:10] woo [18:10] hmm, inappropriate channel [18:26] ali1234: ok, i'll try again with stock xfwm4 and keep the greeter branch first [18:27] ochosi: i think the problem is xfwm4 stores a reference to the pixmap. then later on that pixmap just ceases to exist, but xfwm4 is still trying to draw it [18:27] hm, is there no else for when the pixmap isn't there anymore? [18:27] or an if [18:27] :) [18:45] ali1234: indeed, xfwm4 seems to be the problem... [18:45] or at least some of the root-pixmap stuff [18:46] there's a couple of solutions: xfwm4 copy the root pixmap instead of referencing it, or fully enable MONITOR_ROOT_PIXMAP (and then fix the way xfdesktop does it) [18:47] i think i prefer the latter, it will create less problems [18:47] going to need some extensive reworking though [18:47] hmm [18:48] well xfdesktop is a patchwork piece of code already anyway [18:48] how do i get xfdesktop and xfwm4 to output the tracing logs? [18:48] usually by compiling with --enable-debug=full [18:48] or that's what i'd assume [18:48] i haven't tried it on those two [18:48] only xfsettings [19:11] hm, this belongs here actually... [19:11] ali1234: what do you think about we start up a panel-layout script? [19:12] how do you mean? [19:12] we could start to draft the panel layouts on a wiki page [19:12] e.g. gnome2 [19:12] heh... i'm not the person to ask for that [19:12] unless you want it to be like gnome2 [19:12] well i can draft them [19:12] in which case, yes :) [19:12] and then we could write a simplistic script with a UI that lets people select the panel-layouts [19:13] could it be done with sessions somehow? [19:13] like, we have xfce-session and xubuntu-session now? [19:13] what's the difference between them> [19:13] it could, but it's a bit overkill, no? [19:13] the diff between those is menu-file, autostarted apps and a little more i think [19:13] why? we can put a "classic" menu option on the greeter, people can try it without messing up their config... [19:13] but i don't know off the top of my head anymore [19:14] i dunno [19:14] i'm not sure how a script that does it should work [19:15] i mean, say you've got the XML files... how do you put them in place? just write over the existing ones and then restart the panel? [19:15] basically copy an xml-file to the user's .config directory and restart the panel? [19:15] that sounds really hacky to me... [19:15] yeah, it's dirty [19:15] it's a script [19:15] what about adding a "presets"? like, when you press "new panel" in the configuration, it could offer you some preset panels... [19:16] that'd be nice [19:16] but much more work [19:16] also there's the issue of configurating the individual plugins [19:17] like if you want a "settings" menu, that's actually a customized main menu, not a separate plugin [19:17] well those are in .rc files in the same directory [19:18] yeah, what i mean is it would be difficult for the top level panel prefs to deal with that [19:18] well you can also do it with launchers theoretically [19:18] right [19:18] i do think, if we make a tool for this, it should do everything by the xfsettingsd API [19:18] yeah, that would be ideal [19:19] much better than just copy-pasting [19:19] does that have python bindings? [19:19] it used to [19:19] cos it would be much easier than writing this in C... [19:19] i'm not sure they're still up-to-date and working [19:19] let me check [19:19] (or some other scripting language would do, i guess) [19:19] vala? :> [19:19] there were perl bindings it seems [19:20] last update 2009 [19:20] hm, maybe this? http://git.xfce.org/bindings/pyxfce/ [19:20] looks like it supports xfconf [19:22] doesn't seem to be packaged [19:22] hm [19:24] well if they work we could work towards getting them packaged [19:25] well... i don't like packaging :P [19:26] also, it's another dependency [19:27] maybe we don't need bindings... maybe it can be done with gir or dbus or something [19:28] you could also write a bash-script :D [19:29] and the launcher to the "panel settings app" simply opens a terminal with the script [19:29] it needs a UI though... [19:29] we could make it look like the good old alternate installer [19:30] ochosi, I looked into pyxfce a month or two ago, it wouldn't work [19:31] hm, would really be nice to have python bindings though [19:31] many ppl like it and it's a lot more accessible than c [19:31] yeah. I'll see if i still have why it didn't work. [19:31] It's also a dependancy of rabbit-vcs-thunar [19:31] to start with we need code to load and save the configuration. that can be a command line app, for testing at least [19:32] and we need to figure out the format to store the configuration presets [19:36] indeed [19:37] i guess we use the same xml format as xfconf [19:37] and borrow the loader from it [19:40] that makes sense [19:41] also because that way the xml files are also easy to generate [19:41] but the plugin settings will really add another layer of complexity [19:41] i think we'll have to simply copy-paste the .rc files in that case [19:41] actually, it's all in one xml file [19:42] darn, i should clean up my /home at some point [19:42] i've had it for ages, so there's still old panel stuff lying around there... [19:44] hmm... xconf can only do new, edit, reset [19:44] there's no delete... weird [19:49] hm, gotta go, bbabl [19:49] then i can start with some panel layouts [20:17] Is there actually a current version of pyxfce or thunarx-python? [20:18] not pyxfce [20:18] Also, i now have gthumb 3.2.5 on mentors, still needs uploading. https://mentors.debian.net/package/gthumb [20:43] lderan: ping if you've got time [20:46] elfy, ping [20:47] evening :) wanted to know if you'd had time to look at a/pilot at all yet - and if you have - is it actually going to be of any use to us [20:47] the abiword conversation you were having with dan didn't look hopeful [20:48] haven't gotten it working with the applications from xfce yet [20:48] (settings manager, screenshoorter and so on) [20:49] do you think you will? at least in time for it to have any impact on trusty? [20:49] can't say for certain but its a possibility, need to do some more digging about to find the root cause. [20:49] k [20:50] a while away from a resolution then I guess :) [20:50] hoping its something tiny [20:50] :) [20:51] I'll do a mail to team - asking for what people would like to see on our list to aim for then [20:52] sounds good to me :) [20:52] pointless anyone working on screenshooter or transmission or anything if we're not thinking it's worth it for us [20:52] imo at least [20:52] screenshooter++ [20:52] transmission... ok [20:53] they were just examples that are in my head because I'd just seen them in words :) [20:54] knome: not an easy way to mail the team then [20:54] elfy, just send to -devel and include "team" somewhere in the title ;) [20:54] :) [20:55] i think screenshooter still has the missing about popup :P [20:57] lderan, didn't that get fixed when we added xfhelp back? [20:58] transmission is in everything, so i'm trying to do it. screenshooter is just because it's small and i could copy/paste a lot of stuff once xfce supports autopilot [20:58] Noskcaj, will check, more then likely im out of date with it [20:59] hi Noskcaj [21:00] hey elfy [21:02] lderan: I've put you on the QA blueprint now as looking at a/p [21:03] okay :) [21:07] * lderan downloads xfce settings manager source and begins the madness [21:11] ok - a simple and bare mail gone to list for team [21:11] suitably marked as TEAM :) [21:23] Noticed another one in the docs: http://paste.openstack.org/show/7VequFfQXDkeEU7T5ntD/ [21:28] knome: when something gets posted on the website blog does it get posted to twitter and facebook page automatically? [21:28] elfy, nope [21:28] ok [21:29] elfy, that's handled by me and pleia2 currently [21:29] ok - thanks [21:30] knome: Mind merging that in? [21:31] Unit193, there isn't a merge proposal [21:31] :) [21:31] Sure there is! I propose you merge it. ;) [21:31] lol [21:31] i'll have a look at that later if i remember [21:32] Does bzr add then commit later not add all files? I know with git you'd have to use commit -a for that, but not sure with bzr (I can't merge all changes.) [21:33] it should do [21:33] Unit193, or git add . :) [21:33] yay for git add . [21:33] though i think my git said that's becoming the new default way to do things [21:33] or then it was bzr [21:34] but it was related either to that or delling [21:34] Crap, no it doesn't. [21:35] Dangit, bzr, do what I say not what you think I want. [21:35] its growing sentient :O [21:36] good lord [21:37] can someone give some sentience to launchpad then please [21:39] Or let us use git on it. :D [21:39] knome: I'm proposing one now, you have to exclude all files you don't want committed with -x. -_- [21:40] whaa [21:40] :P [21:40] oh, right, yeah [21:40] true [21:42] OK, should be about done, then. http://i3.kym-cdn.com/photos/images/original/000/234/137/5c4.jpg [21:42] heh [21:43] OK, now bzr is trying to create a keyring, what the heck? [21:43] haha :) [21:44] "Please set a password for your new keyring:" What new keyring?! [21:44] :] [21:46] Message sent to Xubuntu Testers [21:46] let's see what that brings :p [21:48] and hope it's not a stampede of people leaving the team ... [21:48] * Unit193 quits [21:48] Unit193, please do, and join -qa ;) [21:48] knome: I don't test enough. ;) [21:49] And, I think it's proposed. [21:49] pyh [21:51] (https://code.launchpad.net/~unit193/xubuntu-docs/fixes/+merge/196787) [21:51] ta ta [21:52] that shows now up in the xubuntu-docs branch so i'll find it [21:52] Yes, adios. [21:55] elfy: facebook is automatic (it pulls from the RSS feed) [21:56] pleia2: ok - thanks :) [21:56] I can also post links and stuff too [21:57] yep [21:57] now we see if this email causes mass attrition from the team from badge hunters :) [21:57] pleia2: this actually talking to a wider audience is all new as you know [21:57] pleia2: yea :) [21:58] pleia2, ha ha, so witty [21:58] one might not - but after a few it might :) [21:58] :P [21:58] a few pints? [21:58] :) [21:59] knome: so what would be the studio list to send an ask to ? [22:00] https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel [22:00] thanks [22:02] I'll write something to send them re autopilot as well [22:06] I'll say goodnight now though [23:19] haha... i know exactly what is happening [23:20] xfdesktop starts, replaces the root pixmap. xfwm4 sees this, takes a reference. next time xfdesktop updates the root pixmap it sends an event. xfwm4 sees this and frees the root pixmap it had a reference to... but that's the same root pixmap [23:21] so now xfwm4 and xfdesktop both have an invalid reference to an already freed pixmap [23:28] something is really badly messed up here... the ID is corrupt when it reached xfwm4, but only when set by xfdesktop, not by others [23:30] wait... that's not it at all [23:30] i see what's really happening [23:30] xfwm4 uses the existing pixmap to render all it's compositing stuff into [23:31] but xfdesktop is also trying to draw into that pixmap too [23:31] xfdesktop creates a new one for this purpose [23:31] xfwm4 initially takes the one made by lightdm which is no longer in user [23:31] -r [23:32] but when it get the xfdesktop one... xfdesktop continues drawing into it, and then xfwm4 starts trying to draw into it *at the same time* [23:32] this is why only the second part of the MONITOR_ROOT_PIXMAP stuff causes crashes [23:35] infact this code inside MONITOR_ROOT_PIXMAP is extremely dangerous because it assumes it can take ownership of any pixmap it finds [23:38] to be safe, it must take a copy of the pixmap in a new buffer [23:38] hmm... this is good... in fact, i can fix this quite easily, and make the code better at the same time :) [23:39] cool [23:43] ali1234: wall of text :) [23:43] so much going on in the background [23:44] but what it actually explain? which crash? [23:48] brainwash: all of them, everything you reported :) [23:48] well, except the gtk theme stuff [23:48] it's actually not a drawing conflict [23:48] what is happening is xfwm4 finds the pixmap and then tells the xserver to turn it into a XRender picture [23:49] i assume this means "upload it to GPU memory" effectively [23:49] at this point, it's not a normal pixmap any more, so xfdesktop can't draw into it, and when it tries, bad things happen [23:49] anyway the fix is simply to dupe the image [23:50] the good thing about this is it will only happen once on startup, and only if the greeter left an image there for us [23:50] ok.. but everything works with your patches as of now, doesn't it? [23:50] but, the monitor code can then be safely enabled too, if anyone wants to [23:50] no, far from it... [23:51] visually it does :D [23:51] well, not counting the theme issue and the screen corruption [23:52] the screen corruption is the problem [23:52] that i'm fixing [23:53] that's a critical one [23:53] for me at least [23:54] because it forces me to reboot