[00:12] ali1234: what's broken in xfdesktop? [00:12] what *isn't* broken? :) [00:12] the whole multiple desktop and workspace thing... doesn't work [00:12] and when you relog it resets the wallpaper to default [00:14] only tested it once, set a different wallpaper for every workspace and it worked and was consistent === xnox_ is now known as xnox [00:14] yes, that's the *only* case where it works properly :) [00:14] where you set a unique wallpaper for every monitor and workspace, without any spanning [00:15] oh [00:15] if you have two monitors and you set a wallpaper to spanning it doesn't work properly, and if you set "same on all workspaces" it doesn't work properly [00:16] when you start it up it tries to get the wallpaper for each workspace and monitor [00:16] if that fails it looks for legacy settings [00:17] the new version uses the monitor plug name, legacy uses the number [00:17] that means that defaults have to be set using legacy, because we can't know the plug name in advance, it's something like "DVI-I-0" [00:17] but that means that there is always a legacy setting [00:17] is the monitor naming consistent or does it change? [00:17] it's consistent on a single machine if you don't even unplug anything [00:18] so anyway, there are legacy settings in the defaults.xml, which means they can't be deleted [00:19] that means when you log in and you didn't specify a wallpaper for some monitor or workspace, it tries to load the legacy setting and that resets your whole system to defaults [00:19] also sometimes it loads up the default wallpaper and then quickly changes to what you asked for [00:19] wow, so much fun with a multi monitor setup [00:19] + xfdesktop :) [00:19] yes [00:20] and further more i can't even set the wallpaper on all my monitors because some of them overlap [00:20] setting a wallpaper on those monitors wouldn't even make sense [00:20] so xfdesktop and lightdm-gtk-greeter really need some multi monitor rework [00:20] looks like it [00:20] i guess you've seen what gtk-greeter does when monitors overlap? [00:21] no, only running single monitor setups here [00:21] oh... well it draws the wallpaper multiple times [00:21] it's not pretty [00:22] did you also test unity-greeter? [00:22] no [00:22] maybe we can do some copy&paste [00:22] maybe [00:22] probably not though [00:23] hang on let me try it... [00:24] at least to get an idea on how to improve it (in case unity-greeter handles it better) [00:24] heh [00:24] brb [00:28] xfce4-session-4.11.0 has been released [00:32] How much of the new 4.11 stuff do we want for 14.04? [00:33] Everything but session is now packaged for debian [00:34] should we go full 4.11? :) [00:37] If the release team allows it, i want to [00:37] minimum is settings bugfix release, ui bugfix release, garcon [00:38] I see lots of bugfixes in the various changelogs [00:40] maybe it's worth to ship the full 4.11 setup [00:45] how do i change the lightdm greeter? [00:49] ochosi: accounts service background works in test mode but not in the real login window [01:19] ok so unity-greeter is even more hilariously broken [01:19] it doesn't honour the monitor layout at all [01:19] so by default all the monitors do not overlap (it just uses whatever the xorg default is) [01:19] that means you have to reconfigure your monitor layout after every login [01:27] i suspect if it wasn't horribly broken it would show the same thing as gtk-greeter does, which is this: http://imagebin.org/295107 [01:31] ali1234: this would drive me nuts [01:31] well it's better than what unity-greeter does [01:31] which is this: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1283615/+attachment/3992319/+files/IMG_20140223_005551.jpg [01:31] Launchpad bug 1283615 in unity-greeter (Ubuntu) "unity-greeter ignores user monitor configuration" [Undecided,New] [01:32] at least it is *functional* [01:33] mmh, makes me wonder.. was multi monitor support always that bad? [01:33] or do we see some sort of regression here [01:34] maybe hardware/driver related? [01:34] unity greeter used to work properly with xorg.conf [01:34] it isn't driver related [01:34] with unity-greeter you get the default layout as if you had no xorg.conf [01:34] they've obviously decided to ignore it [01:34] which is pants-on-head retarded, so about right for unity [01:35] but yeah, multimonitor support has always been terrible. nvidia is the only way to make it work ina reasonable way [01:35] and they did it by rewriting half the xorg stack [01:36] that bug does not affect unity-webkit-greeter btw [01:36] and probably not lightdm-kde-greeter either [01:36] not at all? [01:37] the webkit one does something very similar to what the gtk one does with multiple backgrounds [01:37] but it honours the monitor layout like it should [01:42] maybe I should extend my laptop screen with another monitor and do some testing [01:45] that would be cool === eric_the_idiot is now known as Guest2522 === eric_the_idiot_ is now known as Guest46634 === yofel is now known as Guest77623 [06:44] Oh right, how did the CC catch up go? === jackson is now known as Guest16889 === Guest16889 is now known as Noskcaj [07:58] it didn't === OutOfControl is now known as benonsoftware [09:12] lderan: you managed to get anywhere writing testcase for your app? === Guest77623 is now known as yofel === yofel_ is now known as Guest39928 [12:10] elfy, is this on the right tracks http://paste.ubuntu.com/6981366/ ? [12:14] lderan: yep that looks fine to me - get it in to bzr push lp:~YOURUSERID/ubuntu-manual-tests/YOURBRANCHNAME [12:14] then I'll check/approve and sync it [12:15] \o/ will do so now [12:15] ok :) [12:17] and i think i've just found a bug with thunar [12:19] I bet it's a known issue :p [12:20] bet so [12:21] if you have 2 rename dialog boxes open the first stops working fully :P [12:23] I can't even open 2 rename dialogues from the same instance of thunar - works fine with another thunar opened [12:24] it partially works for me, the apply button on the first one opens doesn't close the box, but the apply button on the 2nd closes both [12:24] can't confirm that as I can't even get that far :) [12:24] :P === Guest39928 is now known as yofel [12:26] lderan: when you've done that testcase and I've synced the tracker - I'll do a call for testing - but I don't remember the PPA [12:26] shall try to find it for you [12:26] thanks [12:26] biab [12:29] elfy: https://launchpad.net/~light-locker-settings-team/+archive/stable , trust at the moment [12:41] lderan: in future when you do a mr for testcases - don't number them :) [12:41] someone might be syncing one and the number will be wrong ;) [12:41] oh sorry [12:44] lderan: you sure you've finished it? the first 2 tests look decidedly odd and the

won't work :) [12:45] off for a few hours now [12:45] shall check it :) [12:46] can you check spelling too please :) [12:46] cya later [12:46] cheerio [12:46] minuter - must have then copy pasted the same word elsewhere lol [12:47] gah apologies [12:48] ochosi: will get this testcase synced and then called for later today [12:48] elfy: which one? [12:48] light-locker-settings [12:49] oh great [12:49] ty [13:03] elfy, have redone it :P hopefully all okay now [13:31] elfy: shouldn't it be "sudo apt-get update" instead of "upgrade"? [13:34] (re: ML test-case announcement) [14:39] ochosi, you still here? [15:02] lderan: thanks - all done [15:02] ochosi: yep ... [15:08] ochosi, I can't stick around but wanted to ask something about light-locker... [15:08] after testing the light-locker-settings ppa, I tried the light-locker testcase... [15:09] when I click Suspend and go to resume, it brings up the old, flaming xScreensaver dialog. That's not right, is it? [15:09] jjfrv8: purge xscreensaver [15:10] alright, let me try that. [15:11] elfy, that's better. Thanks. Can't keep all the stuff I read in the logs in my head :( [15:12] I did have a note in the testcase to make sure that was done - was sure that the seed had been fixed to not include xscreensaver [15:13] apparently not, this was on a fresh install from today's daily [15:13] mmm [15:16] Fix Committed, not Fix Released. [15:16] thanks Unit193 [15:17] ochosi, also wanted to make sure you had seen that xfesktop Prefs is ready for review. [15:17] bbl [18:51] thanks jjfrv8 [18:51] will review tomorrow [18:58] http://open.knome.fi/2014/02/23/logging-in-with-ubuntu-one/ [18:59] ochosi, you feeling better today? [19:01] Anyone know where micahg went? He's usually online in some form [19:03] * knome wonders how the liquid micah types [19:03] or the gas-form micah [19:06] very very carefully in both cases [19:07] :) [19:08] compressed air then i guess [19:09] Noskcaj: bug 1282509 has been fixed upstream, what is the next step now? normal merge request in ubuntu, debdiff or fix it in debian and sync? [19:09] bug 1282509 in xfdesktop4 (Ubuntu) "xfdesktop crashed with SIGSEGV in xfce_desktop_refresh()" [Medium,Triaged] https://launchpad.net/bugs/1282509 [19:10] I'll ask corsac. The sponsor queue is pretty big currently [19:11] ok, I'm a bit lost, not sure what the best move would be [19:13] why did thunar get SRU'd in 13.10? [19:13] it did? [19:14] the update is crashing all over the place [19:14] apparently [19:15] Noskcaj: can you see error reports on errors.ubuntu.com? [19:15] https://errors.ubuntu.com/problem/cb0629c4765654432162e73197d145eea640134a [19:16] ali1234, No i can't [19:16] although it doesn't look SRUed [19:16] hmm... maybe i'm reading it wrong [19:17] https://launchpad.net/ubuntu/saucy/i386/thunar [19:17] ah, uploaded two months before release [19:17] anyway, there's 17000 reports of that problem ^ [19:18] it's the old magazing_chain_pop_head nonsense again, crashing deep inside glib [19:23] I thought that was fixed in saucy [19:24] still crashing in trusty [19:24] it's on the top 100 most common bugs [19:24] wow. Is there an upstream bugfix? [19:25] I did not notice any thunar crashes in trusty so far [19:25] there is a bug report on launchpad but i can't see that [19:25] bug 1203296 [19:25] Error: Launchpad bug 1203296 could not be found [19:26] 65th most common bug in ubuntu in the past day [19:27] the xfdesktop bug was 48th [19:28] all marked as private? [19:30] public now [19:30] bug 1203296 [19:30] bug 1203296 in thunar (Ubuntu) "thunar crashed with SIGSEGV in magazine_chain_pop_head()" [Medium,Confirmed] https://launchpad.net/bugs/1203296 [19:32] the xfdesktop fix is done in debian. [19:39] that's great, so it will be ready for ubuntu B1, right :) [19:40] hmm... so of the top 10 most frequent crashers in xubuntu, thunar is number 2, 3, 4, 5, 6, 7, 8, and 10 [19:40] brainwash_, Provided corsac uploads it [19:40] and it looks like most of that is magazine_chain_pop_head - which means memory corruption [19:41] ali1234, wow [19:41] in trusty? [19:41] in all versions, past 24 hours [19:42] how is that even possible?! =S [19:45] ah, I recall reading about this [19:45] something related to "Pane Side -> Tree is enabled." [19:45] the tree view [19:49] it does look like the bug was introduced between 1.6.2. and 1.6.3 [19:50] or maybe not [19:51] there are like 3 reports of it with 1.6.2 and 20000 with 1.6.3 [19:55] hmm i see some changes to g_list code... that's the same thing that crashed xfce-terminal [19:55] argh... yeah, this is it [19:55] http://git.xfce.org/xfce/thunar/commit/?id=d5b6768a104786b44542522768d6263cff07a886 [19:56] bad commit... [19:56] it was terminal that we patched to stop magazine_pop_chain, maybe the patch can be modified to thunar [19:57] magazine_chain_pop_head crashes are very generic [19:57] it just means the program did a double free or something [19:57] that commit is suspicious but it might not be it [19:57] any g_list code would be a place to look though [19:57] especially when using prepend [19:57] ok [19:58] basically it means memory was corrupted... it could have happened anywhere in the program, backtraces are not useful :( [20:01] some more g_list stuff here: http://git.xfce.org/xfce/thunar/commit/?id=58fa477fb20aa2ac8eaea8d81d7e4d8c00180600 [20:03] of course it could even be in a plugin... [20:03] how do you trigger the memory corruption? with the tree view? [20:04] Do we want dev-tool or libxfce4util 4.11? both just got uploaded [20:05] util is probably too big a package to do this late, but dev-tools is probably safe to sync [20:05] brainwash_: i don't know [20:06] brainwash_: opening the tree view takes a suspiciously long time [20:09] ali1234: not here, 2sec [20:09] 2 sec is too long [20:09] not for a very slow HDD [20:09] but still.. nothing crashes [20:24] Noskcaj: can you see this page? https://errors.ubuntu.com/?user=a-j-buxton&period=day [20:25] (or anyone else for that matter) [20:27] yep. Turns out i wasn't logged in [20:27] that page should be visible to anyone i think [20:29] It is. [21:12] Noskcaj: watch out when making bug reports public, that thunar one has a torrent download filename in it [21:13] My one? [21:13] 1203296 [21:14] Oops, must have missed that [21:14] that guy likes his torrents, lots on the dupes too [21:15] Is it private info though? [21:15] i dunno [21:15] not the usual linux distro torrents? :D [21:15] it's evidence of illegal activity though [21:16] quick, append "-parody" to each of them [21:16] lots of the dupes were made public by apport [21:16] this is on ProcCmdLine: field btw [21:17] hmm [21:18] "This incident occurred when closing Thunar after moving a file from my PC hard drive to my external drive. The cut/paste operation was complete, I clicked the "X" to close Thunar and got the "Ubuntu experienced an error" message." [21:18] "Thunar crashed after pressing the close button" [21:19] "I closed thunar, this error happened" [21:19] well, that's a pattern if i ever saw one [21:19] thunar has a heap of different errors when it closes. I just made a bug for another one [21:19] "I closed Thunar, and got this error. Pane Side -> Tree is enabled." [21:20] it has all different errors because memory is getting randomly corrupted somewhere [21:20] that can cause many different symptoms, but the root cause is almost certainly the same [21:20] if you can find a way to reliably reproduce it... [21:21] something is overwriting random bits of memory [21:21] probably an uninitialized pointer somewhere === slickyma4ter is now known as slickymaster [22:48] it's particularly telling that all the bugs have roughly the same frequency except for the top one or two [22:49] well, most happened only once [23:01] I'm not affected, because I don't move big torrent downloads from A to B :) [23:04] but thunar needs some cosmetic fixes, 1) use correct icon for "open with" menu entry 2) sort "open with..." sub menu 3) use theme color for selection rectangle [23:04] I'll put it on my todo list [23:06] which versions of thunar have shipped in xubuntu releases? [23:07] !info thunar precise [23:07] thunar (source: thunar): File Manager for Xfce. In component universe, is optional. Version 1.2.3-3ubuntu2 (precise), package size 311 kB, installed size 898 kB [23:07] !info thunar quantal [23:07] thunar (source: thunar): File Manager for Xfce. In component universe, is optional. Version 1.4.0-1ubuntu2.1 (quantal), package size 315 kB, installed size 909 kB [23:07] !thunar raring [23:07] !info thunar raring [23:07] thunar (source: thunar): File Manager for Xfce. In component universe, is optional. Version 1.6.2-0ubuntu1 (raring), package size 320 kB, installed size 899 kB [23:07] hmmmmmmmmmm [23:08] ?! [23:08] this bug has never been reported with raring as far as i can tell [23:08] so it may be a bug in some library [23:08] glib? [23:08] no [23:08] some xfce library that only thunar uses [23:08] !info thunar saucy [23:09] thunar (source: thunar): File Manager for Xfce. In component universe, is optional. Version 1.6.3-1ubuntu1 (saucy), package size 314 kB, installed size 904 kB [23:09] 1.6.2 showed the bug in saucy but not raring, and that was during development [23:10] although actually, it *could* be due to glib changes... same thing happened with xfce-terminal [23:10] shouldn't there be reports outside of the ubuntu universe too? [23:33] yes, but frankly... where? [23:33] arch, debian, suse, mint? [23:34] the only reason i'm seeing these reports is because of automatic error reporting [23:34] i think people tend not to report one-off unreproducable crashes [23:34] mainly because triagers just close the bugs if they can't be reproduced [23:35] i think the only option here is to go through the code and audit it by hand :( [23:36] cppcheck didn't find anything obvious, valgrind isn't showing any corruption... i don't know what else to try [23:37] i'm actually impressed we even got on the top 100 bugs... must be a lot of users out there [23:38] especially since it seems pretty hard to reproduce [23:52] humm, i'm seeing a debian wallpaper on the installer... [23:52] :) [23:55] ali1234, yay?