=== m_conley_away is now known as m_conley === m_conley is now known as m_conley_away [02:12] jbicha: did you not see my comments on the bug for the gparted merge? [02:12] s/merge/sync [02:16] I don't even see a bug for the request [03:20] micahg: no, which bug were you looking at? I was using bug 837213 [03:20] Launchpad bug 837213 in gparted "[Sync Request] Fix NTFS resizing, please update Gparted from Debian" [Wishlist,Fix released] https://launchpad.net/bugs/837213 [03:20] bug 922654 [03:20] Launchpad bug 922654 in gparted "please sync gparted 0.11.0-1 from debian unstable" [Undecided,Fix released] https://launchpad.net/bugs/922654 [03:21] it didn't seem worthwhile to sync a new untested version for alpha2 [03:22] especially being in the live env [03:52] jbicha: the stuff that's not on any images we have more leeway with, but the stuff on images, it's important to weight he decision to update a week before a release (alpha2 is next Thursday and we're frozen for stuff on images Mon at 21:00 UTC) === fenris is now known as Guest25296 === Guest25296 is now known as ejat === s9iper1_ is now known as s9iper1 [12:47] hi, what's keeping this from being merged? https://code.launchpad.net/~jconti/indicator-applet/gnome3/+merge/80877 [12:48] would be great to have it in precise... === s9iper1 is now known as bil21al === bil21al is now known as s9iper1 === Zdra is now known as xclaesse [22:39] jasoncwarner_: You around? [23:16] TheMuso: yup [23:20] Quick question - does anybody know where on the filesystem the list of startup applications is maintained? [23:24] ian__: you might be looking for /etc/xdg/autostart [23:24] in /etc/xdg/autostart and ~/.config/autostart, by default, for the stuff that's not hardcoded in gnome-session at least. [23:24] but that's on a GNOME system. [23:24] well autostart dir is used by KDE and XFCE too [23:24] blackbox maybe not [23:25] but this also isn't #kubuntu-desktop :) [23:25] so i presume he means in the default ubuntu [23:27] dobey: sure. I qualified it because I have no idea (or concern) for what Canonical's Unity is or isn't doing. [23:27] unity uses gnome-session and is a compiz plug-in [23:28] Here's my problem [23:28] I have one user on 11.10 for whom the vino-server isn't running when that user logs in [23:28] All the other users, vino-server is running [23:29] Vino-server doesn't appear under the list of startup applications [23:29] perhaps that user disabled it then [23:29] check that user's ~/.config/autostart directory [23:29] But there was a patch documented in the change-log that shows it was patched to HIDE it from startup applications [23:30] OK -- I have a clean VM of Ubuntu here - and my user doesn't have an autostart directory in .config [23:30] right [23:30] disable something in startup applications, and you will, though [23:30] So I need to know how is vino-server started? [23:31] it is started via the autostart config [23:31] And where's that? [23:31] so that user which doesn't have it, probably disabled it before the patch was applied to hide it from the GUI [23:32] I have a fresh install VM in front of me - not the computer that exhibits the problem [23:32] so look in that user's ~/.config/autostart directory [23:32] and remove the vino-server.desktop from that directory, and it will start again when that user logs in [23:32] There isn't one on this machine [23:33] And it's a clean 11.10 x64 install [23:33] of course there isn't [23:33] it's a clean install [23:33] that user doesn't exist there [23:33] you just said "this isn't the machine that exhibits the problem" [23:34] That's right - I'm looking on the VM to find out where vino-server is started from for a user that doesn't exhibit the problem [23:34] When I've found that out, I'll fix the faulty machine [23:34] Sorry if I didn't make myself clear [23:34] as i already told you, it's started by the xdg autostart configuration system [23:35] by default, the file that causes it to be started on log-in is in /etc/xdg/autostart [23:36] Ahh! I see - there's a file /etc/xdg/autostart/vino-server.desktop [23:37] But isn't that file system level? i.e. Doesn't that file execute regardless of the user that logs on? [23:37] yes [23:37] unless, as i said, the user has diabled it previously, in which case a similar file will be in the user's ~/.config/autostart directory which disables it [23:38] So if that's the case, how comes that on the faulty machine, I have ONE user login, after which once the login takes place, there's no vino-server process running? [23:38] For all others, the vino-server process is visible? [23:39] because that user disabled it at some point [23:39] i.e. I have 3 users - 1 of which I can't control the desktop? [23:39] All three have identical settings for remote desktop [23:40] did you do what i said to do 10 minutes ago, yet? [23:41] Hold on - I didn't understand - reading it again, you're telling me that the FAULTY user will have an autostart directory in .config [23:41] Now I understand [23:42] I have to go onto the faulty machine, log on as the faulty user and remove the file from the autostart folder created in .config [23:43] yes [23:43] Thanks - I'll check that out