[00:15] brainwash: so are you certain the value should be flipped? or does that fix it for one person? I can switch it and see if the reports get worse, the logs don't get me anywhere [00:19] the bug does not affect me with either value, so if that is a good fix for people, just let me know [00:19] hmm, i noticed a variant of the black screen bug today btw [00:19] hey ochosi [00:20] it has surely been described out there, but it's different from what i have seen myself before [00:20] and it confirms my long-time suspicion that there are several, distinct black screen bugs [00:20] so... [00:21] bug 1: with nouveau drivers and locking, i don't get to the greeter, immediate black screen and lockdown, no way to get anywhere other than hard-reboot [00:21] bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [00:21] Good one. [00:22] bug 2: with nvidia drivers bug 1 doesn't happen, but if i use DPMS standby and then close the lid, the display will still be in DPMS standby after waking up. the only way to resolve that is by running something like "xrandr --auto" which wakes up the display [00:22] Error: Launchpad bug 2 could not be found [00:22] bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [00:22] I think that bug 1 is actually the greeter crashing based on some reports I've seen [00:22] same hardware and setup obviously [00:22] apart from the graphics driver [00:23] the second one there has been described by others [00:25] yeah, i think both have been described [00:25] frankly, i'm not sure what to do about either [00:25] i mean i know how to work around both issues and i think many users have figured that out too [00:26] bluesabre: flipping the value seems logical and appears to work fine, but doing it breaks xfpm -> ignores lid close action [00:26] but in order to really fix it, we'd have to understand why e.g. the display can go into a sort of DPMS lockdown mode from which it just doesn't want to wake up by wiggling the mouse [00:26] bluesabre: according to b3nmore [00:27] right... thats exactly what is being disabled [00:27] so, whatever the value is, something will be broken [00:29] so, we're at the same conclusion more or less that we had when we discovered the issue...? [00:29] was it to change the value? [00:30] that things still aren't understood and fixing one thing breaks the other? [00:30] I'll flip it tonight in -default-settings and we'll go from there [00:30] wait a sec [00:30] I think we just need someone to test this [00:30] a handful of people [00:31] no, obviously one person won't cut it [00:31] even a handful might not [00:32] it works for many, we've had a lot of confirmed reports with the current settings [00:32] in xfpm 1.4. logind-handle-lid-switch=true means "logind, please handle the lid switch", right? [00:33] and it would be the fix for the black screen bug (bug two) [00:33] so, this fix is currently not applied to 14.10 and 15.04 [00:34] yeah, but that ^ should only be applied (and in the bg, by xfpm) if "lock-on-suspend" *and* "suspend on lid close" are true [00:35] what is odd is that it doesn't seem to happen, at least when i try with xfpmsettings while monitoring the xfconf channel [00:36] b3nmore mentioned that disabling light-locker also disabled suspend on lid close (with logind-handle-lid-switch=true) [00:36] what version of ll and xfpm did he use for that? [00:36] the versions available in 14.10 [00:37] !info light-locker utopic [00:37] light-locker (source: light-locker): simple session-locker for lightdm. In component universe, is optional. Version 1.4.0-0ubuntu1 (utopic), package size 45 kB, installed size 938 kB [00:37] !info xfce4-power-manager utopic [00:37] xfce4-power-manager (source: xfce4-power-manager): power manager for Xfce desktop. In component universe, is optional. Version 1.4.1-0ubuntu1 (utopic), package size 80 kB, installed size 395 kB [00:38] we could keep him busy and ask him to test 15.04 [00:40] in any case, I'll look at the xfpm code, maybe I can spot something odd [00:51] if you find anything, feel free to tweak things and provide patches if possible... I'm not going to spend much more time on this issue without a lead when there are higher-priority items [01:19] bluesabre: http://bazaar.launchpad.net/~light-locker-settings-team/light-locker-settings/trunk/revision/112 [01:20] line 154 confirms that the default value should be true in utopic, because lock-on-suspend is enabled by default [01:20] ok, that seems reasonable... so using light-locker-settings fixes the issue for folks? [01:23] if you use light-locker-settings to change some settings, then it might update the logind-handle-lid-switch to true (because lock-on-suspend is checked) [01:23] but what happens if you tell xfpm to do nothing on lid close while logind-handle-lid-switch is set to true? [01:24] dunno, currently evaluating that since we now have light-locker settings in xfpm [01:24] -> xfpm lets logind do the job which is to suspend the system [01:24] http://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-manager.c#n338 [01:25] yup [01:25] thats correct [01:26] meh [01:26] :) [01:48] bluesabre: any idea how to keep lls and xfpm in sync? [01:48] use lls, it does that by itself [01:49] yes, but my example shows the bug [01:49] so you will have to rerun lls after changing the lid close action in xfpm [01:50] when you toggle the setting in light-locker-settings, it changes the relevant xfpm setting as well [01:51] I know, but what if you don't open lls after changing something in xfpm? [01:52] xfpm does not alter the value of logind-handle-lid-switch dynamically [01:52] the user needs to rerun lls to update the value [01:53] or am I wrong? [01:53] that's why we're integrating light-locker settings into xfpm, because that is an issue [01:53] there's no sane way to keep them synced otherwise [01:54] exactly [01:54] unless there was a light-locker-settings daemon running at all times [01:55] now we know what is broken.. but it cannot be fixed easily for 14.04/14.10 [01:56] Not something that can be upstreamed? [01:57] it can-ish [01:57] upstreamed? [01:58] isn't this a xubuntu/light-locker thingy? [01:58] we're still limited because light-locker doesn't have a way to kill itself [01:58] process killing in bsd is no-go, so we're not there just yet [01:58] but the plan is to bring it to xfce soon [01:59] ah, that's nice [01:59] light-locker is developed by xfce devs, so its kind of an xfce goodie [01:59] yeah [01:59] or baddie as it mostly seems [01:59] :\ [01:59] also, hi Unit193 [01:59] Hello, bluesabre. [02:00] any good ideas for fixing xfpm building? I'm stumped [02:01] Yes, I pinged you about that even. :P Seems something is broken somewhere as whatever is copying the files into m4/ doesn't create the directory first. As a "hack", in the latest xfce4-screenshooter I called 'mkdir -p m4/' first. [02:01] yeah, saw that [02:01] I'll take a hack :) [02:02] OK, adding. [02:02] thanks [02:02] bluesabre: now we have all the details, so what can we do about this xfpm launchpad report? advise the user to use lls and forget about the issue -> "won't fix"? [02:03] post our findings, and we'll go from there. We'll probably be able to add xfce4-power-manager (Ubuntu) as an affected project soon [02:03] bluesabre: Did you edit the recipe? [02:04] bluesabre: alright, I will do that [02:04] Unit193: I copied it to my own and poked it [02:04] or if you mean, its still pointing to your branch [02:04] bluesabre: Well, meaning I moved xfpm-pkging to ~xubuntu-dev/+junk/ like I promised I would. [02:05] yeah, never updated the recipe [02:05] lazy bluesabre [02:05] or busy, not sure anymore :D === jhenke_ is now known as jhenke [11:54] ochosi: bug 1411959 [11:54] bug 1411959 in indicator-sound (Ubuntu) "Hide autostart launcher in Xfce" [Undecided,New] https://launchpad.net/bugs/1411959 [11:54] looks ok, or? [11:59] currently the autostart launcher for indicator-application is enabled in Xfce. I think this may cause the following problem: remove the indicator applet from the panel and restart. now the autostart launcher will try to launch the indicator-application-service, and therefore nm-applet may try to load its indicator icon. however, there is no indicator area (we removed the plugin from the panel) and [11:59] nm-applet most likely then fails to fall back to the normal tray icon. [11:59] result: no network icon in the panel at all [12:02] ochosi: also, I'll try to SRU https://code.launchpad.net/~thad-fisch/ubuntu/trusty/xubuntu-default-settings/lp1292290 [12:02] it fixes the keyboard shortcut messup partially [13:48] brainwash: nice find for the autostart one [13:57] bluesabre: please test and comment :) [13:59] not about the nm-applet problem, but that hiding the launchers does not break the indicator plugin -> indicators are still loaded fine [14:13] bluesabre: anything concrete to do about "Provide patches as needed to support latest uploaded Gtk version"? seems to me that there is nothing much for us to do there [14:14] there are probably things that need patches here and there, but I think that item is probably done once I upload the next shimmer-themes [14:14] yeah, i mean the patches mostly seem to be in the theme [14:14] or did you change any app code in menulibre/catfish/mugshot for 3.14? [14:15] brainwash: can't remember what you said about that, but are you going to propose the xdg-utils branch with your patch? [14:17] bluesabre: anyway, feel free to mark that workitem as inprogress or done that [14:17] will do [14:17] also, "Review shared components (GNOME-based or otherwise)"? [14:17] isn't that sort of done too? [14:18] and it seems to be more or less the same as the previous workitem [14:18] "Investigate reducing dependency on GNOME components" [14:19] yeah, I don't think we're going to do any more for those this cycle [14:19] I'll mark them off [14:19] cool, thanks [14:19] just wanna keep a bit better overview over what we should focus on [14:21] ochosi: there are 3 things to do: drop obsolete upstream patch from debian/patches, apply the xset timeout patch, apply your ll integration patch [14:22] could be 1 big commit :) [14:22] brainwash: 1) is already approved, but not merged/released yet, 2) is up for you [14:22] and 3) is for later [14:22] I see [14:23] afternoon both [14:23] ochosi: I actually wanted to wait a bit more until the patch is accepted upstream, maybe something could be improved [14:23] brainwash: 3) needs changes in light-locker to use the kde dbus spec, otherwise it won't work or the xdg-screensaver patch will just be too big [14:24] yeah, but we don't wanna wait for upstream cause that could take ages [14:24] heh [14:25] the script is crappy already, your patch won't make that much worse [14:25] and it's working, so from my pov it's approved [14:26] i can probably get it merged and uploaded in ubuntu, so just propose the branch already [14:27] I'll try to do it [14:27] k, ty [14:28] ping me when it's done [14:28] or just subscribe me as one of the reviewers [14:28] it would be fun to think that warty comes back after vivid... http://people.canonical.com/~ubuntu-archive/packagesets/ [14:29] muhahahar [14:29] yeah, that'd be awesome [14:29] also, why in the world did they skip "a"? [15:15] anybody using askubuntu and has 50+ reputation? [15:16] the "best" answer at http://askubuntu.com/questions/62564/how-do-i-disable-the-guest-session?newreg=22b63e6eb35b4fbc984914ac3742d844 would be better if there was a comment that said that you need different values for xubuntu... [15:16] ironically, the answer that is not the best would work with xubuntu too.. [15:19] i do. what do you want me to do? [15:19] reply the answer that is voted the best telling that you need a different greeter and user session for xubuntu (and other flavors) [15:20] you can also mention that the method provided below (creating a file with only the allow-guest option) works for all flavors without extra steps [15:22] someone already wrote this in the commends [15:23] and writing stuff like "the answer below" tends to go wrong if the answers move around [15:24] ali1234: do you have enough rep to edit answers ? [15:24] yes [15:25] copy pasting the second highest answer over the highest answer seem bit rude though :P [15:25] then do that rather than muck about with comments [15:25] yeah that's what i'm thinking... trying to figure out how to do it properly [15:25] not what I meant - just edit the 'best' with a comment [15:25] maybe 'Don't do this for all flavours - only for Ubuntu, see foo for other flavours' [15:26] something like that [15:26] yeah that sounds good [15:26] i'll have to go and look up how to do formatting though :) [15:26] an ftr if something like this comes up again - have sufficient rep too [15:26] ali1234: :) [15:28] i don't actually have enough rep to edit without the edit being approved [15:28] oh [15:28] I do [15:28] have you edited it? [15:28] if not do it - then I'll approve that :) [15:29] oh wait sorry actually i do :) [15:29] not got a thinking head on currently - or rather have but I'm thinking about food ... [15:29] ali1234: ok :D [15:30] lol [15:30] thanks ali1234 and elfy [15:48] this is a mess [15:52] okay done [15:52] :) [15:53] look good, thanks again [15:53] i'm not entirely happy with it, mean the deciding factor is what greeter you use [15:53] but fixing it would be a full rewrite of the whole page [15:53] how so? [15:54] well i could switch my greeter to unity-greeter right now if i wanted [15:54] i'd still be using xubuntu [15:54] with the answer you are pointing to, it doesn't matter [15:54] and the first answer would work for me :) [15:54] true, true [15:54] that's why it should be the best answe [15:54] i'm also wondering if 14.04+ should be first [15:54] and the older ones last [15:54] inside that answer [15:54] but that's minutiae [15:54] there's probably a style guide somewhere for all of this [15:55] style guide for askubuntu? good luck... [15:55] stack exchange sites always produce large amounts of bureaucracy like that [15:55] i stopped really following it a couple of years ago [15:55] about the same time i stopped using unity actually [15:56] cos that's all anyone ever asks about there [15:56] hah, i got a badge for that edit [15:56] congrats [16:11] :) [16:12] I have 316 rep, not sure how much one can actually do with that [16:15] ah, requires 2000 to edit [16:15] better get to work then [16:15] haha [17:16] ochosi: should I update the debian changelog for my MR? [17:16] not even sure, if I should have applied the patch or just add it to the series file [17:28] brainwash: add the patch in debian/patches, add it to debian/patches/series, and add it to the debian changelog, but don't apply it --- that is the usual way to go [17:29] that way the diff is just the patch [17:32] gotta run, bbl [17:59] brainwash: you're generally supposed to use quilt when there is a series file [17:59] https://wiki.debian.org/UsingQuilt [18:53] ali1234: I did, but should I apply the patch or just add it? [18:54] I guess it should be applied, otherwise the source code will not change [18:56] https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540 [19:02] you shouldn't do either [19:02] quilt does it all for you [19:04] I mean should I quilt push my patch before uploading my branch? [19:04] no [19:05] you should quilt pop -a [19:05] this will revert all patches [19:06] yes, that's the whole point [19:06] but the package branch has all current patches applied [19:06] there is a reason why the patches are stored in the debian folder [19:07] packaging is a mess [19:08] you've commited the .pc folder by the looks of it too [19:08] especially if you have to mess around with a some ubuntu package with has like 10 debian patches.... [19:09] packaging is really easy if everyone who touches the package knows exactly what they are doin [19:09] unfortunately nobody knows what they are doing [19:10] well, the guy who will do the merge can clean it up :) [19:10] that's what i generally assume as well [19:10] looks to me like this package is in a really poor state anyway [19:10] it is [19:11] the .pc seems to have been checked in ages ago [19:11] you're not supposed to keep that directory [19:11] it holds the current status of quilt ie what patches are applied [19:11] I know [19:12] you're *supposed* to unapply all patches and keep them as individual files in debian/patches [19:12] that's why I am confused [19:12] don't be confused, just assume that nobody has any idea what they are doing [19:14] yeah.. pulseaudio 4.0-0ubuntu22 [19:14] 22 [19:14] and vivid seems to be stuck with version 4 [19:14] ?? [19:15] !info pulseaudio vivid [19:15] pulseaudio (source: pulseaudio): PulseAudio sound server. In component main, is optional. Version 1:4.0-0ubuntu22 (vivid), package size 699 kB, installed size 3712 kB [19:16] I mean, some packages are bloated with patches and then get stuck with this version [19:16] well if there is no upstream release, what do you want? [19:17] debian has pulseaudio 5 [19:19] there's probably a reason for this [19:19] like it breaks the unity phones [19:19] ubuntu phone [19:19] yeah [19:19] luckily they did not break indicators again [19:19] for one thing you can't use a bluetooth headset with it [19:19] that's kind of a showstopper for a phone [19:20] sound indicator isn't working here [19:20] here? [19:20] working fine here [19:21] nor if I boot with a usb [19:21] I only heard some complains about the dropbox icon which seems to be missing [19:21] that is a dropbox bug [19:21] not even sure, if dropbox uses the indicator interface [19:22] it doesn't [19:22] it's like skype [19:22] ochosi seemed to think it was broken somewhere [19:22] it uses appindicator or notify [19:23] indicator-sound works for me, i installed yesterday [19:23] elfy: then we need to know if we can somehow reproduce the bug [19:23] possibly stopped working when I installed new sound card [19:23] that's not a common task :D [19:24] common enough [19:25] however at the same time - clean install - so not anything floating about in home [19:28] all you can do is to file a report, any maybe contact someone in #ubuntu-desktop [19:28] not that concerned tbh - don't use it anyway [19:29] certainly not wasting my time in that channel again [19:30] contrary to the 'we shouldn't break things for flavours' the only time I bothered going there I got an 'as long as it works for us' impression [19:30] the trick is to not give up [19:31] remind them every day that they failed [19:31] not bothering is working fine for me [19:31] if you ever need someone to do this i actually rather enjoy it [19:31] mmm [19:32] well worked for a really old soundblaster card (and I mean old) - doesn't work for a bit younger asus xonar [19:33] what do you mean by "doesn't work" [19:33] doesn't even try to show now :) [19:33] indicator-sound [19:33] soundcard is fine :) [19:34] believe me - I'd be shouting if I had no sound :D [19:34] if it doesn't show then it isn't running [19:34] this is a failure of upstart (again) [19:34] then it isn't running [19:34] mmm [19:34] upstart is just really bad [19:34] didn't think about trying to boot upstart [19:34] it's a shame they won't replace it with systemd in the session this cycle [19:35] boot upstart? [19:35] you can't, it's the session init [19:35] restarting it restarts the session [19:35] the trouble with upstart though is it is event based [19:35] I don't boot with upstart - I boot with systemd [19:35] it doesn't matter [19:35] you still use upsart for session init [19:36] and indicators are part of the session [19:36] mmm [19:36] pid 1 init is the system init and runs as root [19:36] that is systemd [19:36] wonder would would happen if I removed upstart then [19:36] but session init is the first program running as your user [19:36] s/what would [19:36] if you remove upstart the whole xubuntu desktop will break? [19:36] not in a vm it doesn't [19:37] .... i don't believe you :P [19:37] not tried hardware yet [19:37] should make any difference in a VM [19:37] should not* [19:37] i'm going to try it now [19:37] i bet it breaks really bad [19:39] install systemd-sysv that'll remove ubuntu-minimal, ureadahead, and upstart and update grub [19:40] if it does completely go pete tong then we need to shout a lot I would guess [19:40] why? [19:40] upstart will remain as the session init for ubuntu in 15.04 [19:41] that's not what they're planning [19:41] yes it is [19:41] in fact today is the sprint to convert system daemons to upstart [19:42] oh is that what he meant by "ubuntu-minimal, ureadahead, and upstart " [19:42] bah [19:42] me: Are you planning to convert the session services like indicators? [19:42] is that what he meant by "[08:15] and then next cycle address session upstart" [19:42] yes exactly [19:43] even though " [08:15] elfy: so I hope we can flip the switch end of Jan/start of Feb" [19:43] he told me the same on G+ when i asked last week [19:43] aah ok [19:43] flip the switch for pid 1 yes [19:43] right [19:43] there are TWO inits when a user is logged in [19:43] ok - got that now - thanks :) [19:43] pid 1 and the user's private session init [19:43] right now no unity stuff will work without upstart [19:43] and it's not planeed for this cycle either [19:44] which is a pity because frankly indicators worked a lot better when they used dbus activation [19:44] but if someone removes those three packages - what happens then? no upstart so how would any session use it? [19:44] that's like saying "what happens if you uninstall kernel?" [19:44] the asnwer is: the whole system completely breaks [19:44] so don't [19:45] mmm - have to have a go with that now then :) [19:45] btw [19:45] if you actually want to break your system you need to uninstall upstart-bin [19:45] that's what provides /sbin/upstart [19:45] I don't particularly want to - just following that install of systemd-sysv [19:46] so i just did this [19:46] it falls back to xfce4-session... which is nice [19:46] no indicators though as they hard-depend on upstart [19:46] ok [19:46] thanks [19:47] worse than just not having the sound one :p [19:49] can you pastebin a ps waxf please? [19:50] http://paste.ubuntu.com/9769427/ [19:51] okay check lines 156 and 157 [19:52] for some reason upstart decided to only run indicator-messages [19:53] no idea why that then [19:53] have a look in ~/.cache/upstart/ [19:53] there should be lots of logs in there [19:54] yep [19:54] well [19:54] lots of backups I guess [19:54] it does use logrotate [19:54] yep [19:55] only actually have dbus/startxfce4 and a crash [19:55] what about indicator-application-service? it's started differently, not by upstart [19:55] that is a different indicator [19:55] it's because it has a different init script [19:56] last sound one was http://pastebin.com/ES2FM9wD [19:56] okay that would explain why it doesn't work [19:57] should I report this then? [19:57] of course [19:57] actually maybe not [19:58] what happens if you run upstart --user --startup-event indicator-services-start [19:58] it should run them all again [20:01] lol, you get no networking if you remove upstart-bin [20:01] and then you can't reinstall it [20:01] (easily) [20:01] i guess i will just reinstall then [20:01] heh [20:02] ali1234: http://lpaste.net/118631 [20:02] brainwash: meh, i dunno [20:02] the whole upstart event system is really bad [20:02] ali1234: if I run that then sound starts - but there's no menu - just a line where the menu should be [20:02] that means the indicator loaded but couldn't talk to pulseaudio [20:03] is this today's iso? [20:03] this is installed from one from a week or so ago [20:03]