[14:40] <Nafai> Question regarding i10n, as far as the translation mechanism is concerned, N_("Close") is different from GTK_STOCK_CLOSE, right?
[14:44] <Nafai> jcastro: So today, I'm following up with pitti's comments on my brasero changes and then gnome-bluetooth, etc
[14:44] <Nafai> jpetersen: You around?
[14:44] <jpetersen> Nafai, yes
[14:44] <jcastro> rock and roll!
[14:44] <jpetersen> Hello :)
[14:45] <jcastro> Nafai: did you split up vino btw?
[14:45] <Nafai> Yes
[14:45] <Nafai> (did I forget to mention that in my status report?)
[14:45] <jcastro> dunno that was yesterday, sorry I forgot
[14:45] <Nafai> heh :)
[14:46] <Nafai> you've slept since then, I hope
[14:46] <jcastro> heh, yeah
[14:50] <Nafai> I have a couple problems.  In order to remove the icons from the app indicator menu for brasero, I changed the GtkActionEntry to not use GTK_STOCK_CANCEL for the id but to just use N_("Cancel") for the string
[14:50] <Nafai> (The patch is here: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/497853/comments/6)
[14:50] <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete]
[14:51] <jcastro> mpt: when you get a chance please update, log out and back in and check gnome-power-manager's label things in the menu and let us know what you think.
[14:51] <Nafai> But then that messes up the translations
[14:51] <Nafai> But I'm not sure how to remove the icons if I use GTK_STOCK_CANCEL for the id in the GtkActionEntry
[14:51] <Nafai> jpetersen: Any ideas?
[14:59] <Nafai> I need to go run some errands for a while (yay more doctor stuff), but I'll check back
[14:59] <jpetersen> Nafai, hm I do not have a really good idea for that
[14:59] <Nafai> ok :(
[16:06] <jpetersen> I will be offline for an hour will be back later
[16:24]  * Nafai is back
[16:33]  * hyperair wonders if anyone else frequently killall's notify-osd
[16:36] <qense> tedg: Have you had the time to look at my mail lately?
[16:36] <qense> hyperair: never needed, actually
[16:36] <qense> memory leaks?
[16:37] <tedg> qense: Hmm... no, I'm not sure which e-mail you're talking about.
[16:37] <hyperair> qense: yes. =(
[16:37] <tedg> qense: Did I miss one?
[16:37] <qense> tedg: I think so.
[16:37] <hyperair> qense: my uptime is only 6h this round.
[16:37] <qense> tedg: I sent it to the first e-mail address on the list on your Launchpad profile.
[16:37] <qense> Maybe it got spammed.
[16:37] <qense> Shall I sent it again?
[16:38] <tedg> qense: Found it.  Sorry... looking now.
[16:38] <qense> tedg: ok
[16:39] <qense> hyperair: Did you report a bug for that behaviour?
[16:39] <hyperair> qense: i think i did.
[16:39] <hyperair> qense: a long long time ago....
[16:40] <hyperair> (in a galaxy far far away)
[16:40] <qense> It may still get fixed, I just got an update for GNOME Pilot that fixed a bug with a number in the 100,000.
[16:41] <hyperair> qense: i think it's related to the images passed to notify-osd.
[16:42] <hyperair> qense: the higher res pictures you pass to it, the faster it leaks.
[16:42] <qense> weird, what images are you receiving then?
[16:42] <hyperair> qense: and i've got a lot of high-res album art
[16:42] <qense> that could be the cause of it
[16:42] <qense> valgrind!
[16:43] <hyperair> qense: have you ever stuffed a gobject/glib using program into valgrind before?
[16:43] <hyperair> qense: you get a million and one errors and warnings and you can't even tell what's wrong and what's right anymore
[16:43] <qense> hyperair: Frankly, I've never used valgrind before.
[16:43] <tedg> qense: Yeah, the issue is that you're trying to send the enums over dbus -- which really doesn't work.
[16:43] <qense> hyperair: Report them alL!
[16:43] <qense> tedg: not even a tiny bit?
[16:43] <qense> :(
[16:43] <tedg> qense: The values need to be sent over dbus as strings, and then translated back.
[16:44] <tedg> qense: Yeah, one of the reason is that it doesn't match the KDE spec.
[16:44] <tedg> qense: Which is all strings.
[16:44] <hyperair> qense: nobody in the right mind is going to stare at the million and one false positives there are
[16:44] <tedg> qense: We could of course send ints if we weren't matching that spec.
[16:44] <tedg> qense: But we can't send GType enums as the dbus bindings aren't smart enough to turn those into ints.
[16:44] <qense> that's a shame
[16:44] <tedg> qense: So for the parts that touch dbus, they need to be int/strings.
[16:45] <qense> tedg: tedg: The thing is that everywhere in the AppIndicator class they should be of the correct type, otherwise the bindings for C# don't work properly.
[16:45] <tedg> qense: Yeah, we're getting better GLib Dbus bindings in the next rev of Glib -- but that's another 6 months off (at least)
[16:45] <tedg> qense: So can we hide the "dbus parts" of the class from C#?
[16:46] <tedg> qense: Like make the bindings not have some of the signals in them.
[16:46] <qense> tedg: the issues with the bindings are mostly in the set_ and get_property methods
[16:48] <tedg> qense: Can those be wrapped in some clever way?
[16:48] <qense> tedg: Do you really need the set_ and get_ property methods to save and return strings?
[16:49] <qense> Otherwise we would let get_property() translate the string to the correct type and return that.
[16:49] <tedg> qense: Yes, those are the functions that dbus calls to get the properties.
[16:49] <qense> Then we have a problem
[16:49] <qense> the C# bindings call those as well
[16:50] <tedg> Can the C# bindings translate the enum values into strings?  It seems some sort of polymorphism should help.
[16:50] <tedg> So you could still set the value, it'd just translate using the g_* values when it's needed.
[16:52] <qense> tedg: That is only possible to do if most methods of the bindings would be written manually and added to the .custom file, which would mean you'd have to maintain two libraries instead of one. If we can get everything to be generated using the .metadata file, which is what I'm working on, it's just a matter of running the Makefile and everything gets generated just fine.
[16:53] <qense> Moreover, overriding the Fallback and Unfallback methods requires the inheritance of the whole class.
[16:53] <qense> If you want to do that you either need to specify the arguments of the constructor in the .metadata file, which is when GAPI expects them to be saved in the type you're giving.
[16:54] <qense> Otherwise you need to manually write a constructor.
[16:54] <qense> and maintain it
[16:56] <tedg> Hmm, so then in Mono could we ditch the idea of the enums entirely, and let people just use strings through some sort of const.
[16:57] <tedg> You wouldn't get the benefit of the enum, but we'd make it easier to maintain.
[16:57] <qense> tedg: That way we'd only have to implement two custom type definitions.
[16:58] <qense> Which is doable.
[17:19] <Nafai> Hi jpetersen
[17:19] <jpetersen> Hi
[17:22] <Nafai> So I need some advice on this: https://bugs.launchpad.net/ubuntu/lucid/+source/brasero/+bug/497853/comments/8
[17:22] <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete]
[17:22] <Nafai> jcastro, mpt ^
[17:24] <Nafai> Here's the deal.  With the GtkStatusIcon, when you click it once burning is done, it closes.  So, do replicate behavior, I have changed the Cancel menu item to Close in the App Indicator
[17:25] <Nafai> The translation issue is that I have use N_("Close") instead of GTK_STOCK_CLOSE so the icon wouldn't show
[17:27] <Nafai> And I wonder what the help string should be
[17:29] <jpetersen> Maybe it could help to only display images in app indicator when the "always-show-image" property is TRUE for the GtkImageMenuItem
[17:29] <jpetersen> but that probably than does not display some images which should be shown else
[17:29]  * Nafai nods
[17:30] <Nafai> tedg suggested we handle this in each app right now
[17:30] <Nafai> And so I'm struggling to figure that out
[17:30] <jpetersen> Yes
[17:30] <Nafai> For example, my next task is to hide the menu items in gnome-bluetooth
[17:30] <Nafai> I really don't want to mess with the glade file and would rather do it at runtime (minimize changes to go upstream)
[17:31] <Nafai> There are menu items with the icon-name property set
[17:31] <Nafai> Would I just turn it off by setting the icon-name property to "" or NULL?
[17:31] <jpetersen> Yes that should help usually
[17:31] <Nafai> Ok, that's what I'll try
[17:33] <mpt> Nafai, in a user testing session right now, I'll look at it in a moment
[17:33] <Nafai> mpt: thanks
[17:33] <Nafai> jpetersen: Darn, one of the problems with gnome-bluetooth is that it uses stock-id in some cases :(
[17:34] <jpetersen> Nafai, yes stock-id is annoying in that case
[17:34] <Nafai> because that forces an icon because it becomes a GtkImageMenuItem, right?
[17:36] <jpetersen> one could try gtk_image_menu_item_set_image (item, NULL)
[17:37] <Nafai> I'll see what that does
[18:37] <seb128> jcastro, jpetersen: gnome-settings-daemon uploaded to lucid now
[18:41] <jcastro> \o/
[19:03]  * mpt finally gets some time to look at Nafai's bug
[19:03] <Nafai> thanks
[19:03] <mpt> ah, right
[19:03] <mpt> This is one of the applications that shouldn't be in the panel at all
[19:03] <Nafai> oh
[19:04] <mpt> But we have money to burn, so... :-)
[19:04] <Nafai> so much for what I've done :)
[19:04] <mpt> let's see
[19:05] <mpt> Completely not your fault at all
[19:05] <mpt> hm
[19:05] <mpt> Looking at the patch, you have a "Cancel" item and then a "Close" item?
[19:06] <Nafai> Yes
[19:06] <Nafai> cancel for when the burn is in place, and then when it is done, close
[19:06] <mpt> What is the difference?
[19:06] <Nafai> (only one is shown at a time)
[19:06] <mpt> oh
[19:06] <Nafai> this mirrors the dialog
[19:06] <mpt> Is that what the notification area item did too?
[19:07] <Nafai> it didn't change the item
[19:07] <Nafai> but when you left clicked, it closed the dialog and went away
[19:07] <Nafai> it had a right-click menu
[19:08] <mpt> What did the right-click menu have in it?
[19:08] <Nafai> Show and cancel
[19:09] <jcastro> mpt: we could use feedback on the power manager changes that landed today too
[19:10] <mpt> Nafai, and what happened to the notification area menu when the burn was done?
[19:11] <Nafai> no changes
[19:11] <mpt> Nafai, so it still had a sensitive "Cancel" item that did nothing?
[19:11] <Nafai> I think so, let me verify
[19:12] <mpt> don't waste a disc on my account :-)
[19:13] <mpt> Nafai, how about, instead of making the whole thing disappear when you choose "Close", make the whole thing disappear (but leave behind the window) as soon as the job is complete?
[19:13] <Nafai> I can burn to iso, so no biggie
[19:13] <Nafai> Yes, no menu changes
[19:14] <mpt> so we're effectively fixing a bug in Brasero no matter what we do
[19:14] <Nafai> yeah
[19:14] <mpt> Nafai, if you remove the whole menu when the burn finishes you don't need to add a new item.
[19:15] <Nafai> correct
[19:18] <Nafai> mpt: automatically remove the app indicator, and then make sure the dialog is visible?
[19:19] <mpt> Nafai, no need to make sure it's visible, there's no hurry
[19:19] <mpt> maybe request attention on it
[19:19] <Nafai> ok
[19:20] <Nafai> well, you can show and hide the dialog from the menu, which is what I mean by make visible
[19:20] <Nafai> not necessarily bring to foreground
[19:20] <mpt> oh, right
[19:20] <mpt> yes
[19:21] <mpt> jcastro, I've installed them, but haven't had time to restart yet sorry
[19:21] <jcastro> mpt: no worries, I was mulling if the same idea applied to the rhythmbox one would be a good idea
[19:22] <Nafai> thanks for the advice mpt
[19:22] <mpt> jcastro, Rhythmbox would be another example of one that would be counterproductive to port for Lucid
[19:22] <mpt> you're welcome Nafai
[19:22] <mpt> jcastro, oh, but that's mostly done isn't it
[19:23] <mpt> That's why there's people complaining about the tooltip
[19:23] <mpt> Sorry, forgot that, it seems like ages ago :-)
[19:23] <jcastro> mpt: at this rate you're basically saying that porting nothing to app indicators is a good idea
[19:24] <Nafai> :(
[19:25] <mpt> jcastro: gnome-control-center, vino, ekiga, gnome-settings-daemon, gnome-gmail-notifier, xchat all make sense to port
[19:26] <hyperair> oh hey so mpt agrees with me
[19:26] <hyperair> re tooltips
[19:27] <hyperair> gnome-control-center has an application indicator? what does it use it for?
[19:27] <mpt> jcastro, a second class should be adjusted to not use the notification area at all
[19:27] <mpt> jcastro, and a third class (e.g. Tomboy) should be ported eventually, but appindicator doesn't have the special stuff they need yet (e.g. grid layout)
[19:28] <mpt> hyperair, Rhythmbox is in the third class -- not necessarily a tooltip, perhaps a better mechanism ;-)
[19:29] <hyperair> mpt: what do you mean third class?
[19:29] <hyperair> mpt: and i'm speaking from banshee's point of view, which should essentially be the same as rhythmbox in this area.
[19:29] <mpt> hyperair, ^^^
[19:29] <jcastro> hyperair: gnome-cc uses it for the typing break thing
[19:29] <hyperair> ah typing break.
[19:29] <hyperair> i've never used that before. perhaps i should give it a run..
[19:30]  * hyperair flexes left wrist
[19:30] <hyperair> mpt: third class meaning a better mechanism than a tooltip?
[19:31] <mpt> hyperair, maybe
[19:31] <hyperair> mpt: er wait, what are these classes referring to?
[19:31] <mpt> hyperair, categories of applications that have been using the notification area.
[19:32] <hyperair> ah
[19:32] <mpt> we have two goals
[19:32] <mpt> (1) reduce the number of them
[19:32] <mpt> (2) make the remainder behave consistently
[19:32] <mpt> We get #2 by making them a single set of menus
[19:33] <mpt> We're not doing so well with #1 at the moment.
[19:33] <hyperair> mpt: what i don't really agree with is the complete removal of tooltips. i understand that it would be desirable to make them all follow a consistent interface, but menus have text buttons. these are icons without text.
[19:34] <hyperair> mpt: in other words, these are more like toolbar icons that have dropdown menus when clicked.
[19:36] <mpt> I think it would be useful to brainstorm different ways of showing the track info
[19:36] <mpt> It's kind of crazy that music players have been showing it in three different ways
[19:37] <hyperair> three?
[19:37] <mpt> 1 in the player window itself, 2 in notification bubbles, 3 as a tooltip in the notification area
[19:37] <hyperair> i know of the tooltip, what are the other two?
[19:37] <hyperair> ah.
[19:37] <hyperair> well i think 2 and 3 have their own reasons.
[19:37] <hyperair> 1 as well
[19:38] <hyperair> it wouldn't make sense to not show the track in the player window.
[19:38] <hyperair> notification bubbles are transient and show a change of track
[19:38] <hyperair> and tooltips are so you don't have to open the big player window to check the currently playing track, after the notification bubbles have expired.
[19:39] <mpt> Any two of them you could merge, with a bit of work
[19:39] <hyperair> i don't see how #1 could be merged with any of the other two.
[19:40] <mpt> (1) and (2) could be merged by making a pseudo-notification-bubble that appeared in exactly the same place, and with exactly the same layout, as the information in the window wherever the window happens to be
[19:40] <hyperair> #2 and #3 could be merged, by forgoing notify-osd style popups and showing that tooltip for a brief period when changing.
[19:40] <mpt> exactly
[19:40] <hyperair> i don't see how #1 and #2's merge can be even considered a solution.
[19:41] <hyperair> exactly in the same place
[19:41] <hyperair> considering player windows can move all over the place, your notification bubble is going to also move all over the place
[19:41] <hyperair> and it's going to obstruct whatever the user is doing
[19:41] <mpt> notification bubbles already obstruct some people wherever they are :-)
[19:41] <hyperair> notify-osd minimizes that.
[19:42] <mpt> but yeah, it would be more likely nearer the center of the screen
[19:42] <mpt> This is all just brainstorming, not saying any of these are brilliant ideas
[19:42] <hyperair> heh
[19:42] <hyperair> right
[19:43] <hyperair> mpt: there was also the issue about mouse feedback on the notification area icon/app indicator, although that is much less of an issue than the tooltip.
[19:45] <Nafai> what do you mean by mouse feedback?
[19:45] <mpt> ditto
[19:45] <hyperair> Nafai: middle click to play/pause.
[19:46] <hyperair> scroll to change track.
[19:46] <Nafai> oh, I see
[19:46] <hyperair> mouseover for too-er wait, that's tooltips.
[19:46] <Nafai> I never realized that the old rhythmbox thingy allowed that :)
[19:46] <hyperair> i don't speak for rhythmbox. i speak for banshee.
[19:47] <hyperair> tbh i can't be assed about what happens to rhythmbox really =p
[19:47] <Nafai> oh, sorry
[19:47] <hyperair> i'm not sure whether rhythmbox allowed that though
[19:47] <hyperair> it might have
[19:48] <hyperair> i know amarok did during the kde3 days.
[19:48] <hyperair> i'm not sure if it still does.
[19:48] <hyperair> even exaile allows it somewhat
[19:48] <hyperair> i think exaile does volume though
[20:46] <Nafai> jpetersen: Around still? (I realize it is late there :))
[20:47] <Nafai> Or anyone else that might know GtkBuilder or gtk menus in general
[20:48] <Nafai> I'm having a hard time getting a reference to the menu items I want so I can turn off their icon and I could use some guidance
[21:30] <jpetersen> Nafai, hi
[21:31] <Nafai> Hi jpetersen
[21:31] <jpetersen> Nafai, which application is it?
[21:31] <Nafai> gnome-bluetooh
[21:31] <Nafai> gnome-bluetooth
[21:31] <Nafai> So it uses this glade file: http://git.gnome.org/browse/gnome-bluetooth/tree/applet/popup-menu.ui?id=GNOMEBT_V_2_29_91
[21:31] <Nafai> er, gtkbuilder file
[21:31] <Nafai> and then builds the menu: http://git.gnome.org/browse/gnome-bluetooth/tree/applet/main.c?id=GNOMEBT_V_2_29_91#n361
[21:32] <Nafai> if I try getting at the menu item using gtk_builder_get_object (xml, "preferences"), it returns the GtkAction, not the GtkMenuItem
[21:32] <Nafai> And I don't know how to get at the menu item
[21:34] <jpetersen> Nafai, ah yes I think you need to get the ui-manager with gtk_builder_get_object (xml, "bluetooth-applet-ui-manager");
[21:35] <Nafai> Ah, I didn't notice the ui manager there
[21:35] <jpetersen> and than the widget with gtk_ui_manager_get_widget
[21:35] <Nafai> right
[21:35] <Nafai> I think I can do that.  Thanks :)
[21:36] <jpetersen> the path in gtk_ui_manager_get_widget is something like "/bluetooth-applet-popup/preferences" than :)
[21:36] <jpetersen> your welcome :)
[21:36] <jpetersen> I will leave now
[21:36] <jpetersen> good night :)
[21:50] <ryanprior> Is anybody working to patch Gwibber to handle Google Buzz before Lucid?
[21:56] <jcastro> the
[21:57] <jcastro> APIs aren't public yet afaik
[21:57] <sanderqd> http://code.google.com/apis/buzz/ seems you can only retrieve updates, and post them from another connected site


[10:25] <rmg51> Morning
[10:31] <JonathanD> Morning.
[13:11] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[14:45] <MutantTurkey> mornin
[17:21] <InHisName> morning


[05:59] <Kilos> morning everyone
[10:14] <Kilos> hmm...
[11:24] <Researcher> hi kilos
[11:24] <Researcher> morning
[11:24] <Researcher> :)
[11:26] <Researcher> yo rhct
[11:26] <Researcher> saLAAAM
[11:26] <Researcher> let me make tea
[11:37] <Kilos> hi Researcher
[11:37] <Kilos> ill bb as well toilet calls
[11:40] <Kilos> you have lots of work
[11:50] <Kilos> i hope you had a good holiday
[12:03] <Researcher> tnx kilos
[12:12] <rhct> hi
[12:12] <rhct> brb
[12:12] <Researcher> ok
[12:29] <Kilos> she is written in python but works only in 12.04 without hitches because since python went to 3 she cant work
[12:30] <Kilos> one of my guys is busy rewriting the whole thing atm as well , but you know what it is like when you have to code in your spare time
[12:31] <Kilos> anyone can get the code and use it as well
[12:31] <Kilos> just need up to date good python programmer
[12:31] <Kilos> QA hi
[12:31] <QA> wassup
[12:31] <Kilos> QA coffee on
[12:31]  * QA flips the salt-timer
[12:32] <Kilos> Researcher pavel has learned some of the commands to use with ibids
[12:35] <QA> Coffee's ready for Kilos!
[12:36] <Kilos> QA ty
[12:36] <QA> Only a pleasure Kilos
[12:38] <Kilos> QA help
[12:38] <QA> Kilos: I can help you with: looking things up, remembering things, delivering messages, decisions, games, monitoring things, browsing the internet, conversions, silly fun stuff, calculations, system administration, software development and south african stuff.
[12:38] <QA> Ask me "help me with ..." for more details.
[12:39] <Kilos> QA help me with software developement
[12:39] <QA> Kilos: I use the following features for software development: base64, retest and rfc
[12:39] <QA> Ask me "how do I use ..." for more details.
[12:39] <Kilos> QA how do i use software developement
[12:39] <QA> Kilos: I'm afraid I don't know what you are asking about. Ask "what can you do" to browse my features.
[12:40] <Kilos> QA what can you do with software developement
[12:40] <QA> Kilos: I'm afraid I have no idea
[12:40] <Kilos> lol
[12:40] <Kilos> QA what can i do with software developement
[12:40] <QA> Kilos: Erk, dunno
[12:41] <Kilos> i have forgotten
[12:43] <Kilos> Researcher well leave a large space for belkinsa before the complaints start so she doesnt have too much scrolling to do, she is also very busy
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:43] <Kilos>
[12:44] <Kilos>
[14:44] <Kilos> pavlushka Researcher
[14:44]  * Kilos waves
[14:45] <Kilos> Researcher doing washing before water is finished
[14:45] <Kilos> hi zaki
[14:46] <zaki> hlw everyone..
[15:18] <Researcher> hi zaki
[15:18] <Researcher> salaam
[15:18] <Researcher> kaisay hain aap
[15:19] <Kilos> let me catch up zaki
[15:19] <Kilos> last one looks good yes
[15:19] <Kilos> one more time please
[15:20] <Kilos> pavlushka where you went
[15:20] <Kilos> are you busy lad?
[15:20] <pavlushka> i was away, but didn't checked the away status, sorry
[15:20] <Researcher> hi pavlushka
[15:20] <Researcher> welcome back
[15:22] <pavlushka> Researcher: thanks
[15:23] <pavlushka> Researcher: got my memo?
[15:23] <Researcher> no i wasnt got dc so never recieved one
[15:25] <Researcher> hi zaki
[15:25] <Researcher> wb
[15:26] <Researcher> today may be i will not be available
[15:26] <Researcher> so guys sort it out together
[15:26] <Researcher> from tomorrow i wil be spending 7 to 8 hours atleast every day here
[15:27] <zaki> hi Researcher
[15:27] <Researcher> hi hi
[15:28] <Researcher> zaki glad to see you here
[15:28] <Researcher> and welcome to the loco team pakistan
[15:28] <Researcher> brb guys i have to go out with family for a dinner
[15:28] <Researcher> :)
[15:29] <Researcher> take care everyone
[15:29] <Researcher> thanks kilos
[15:29] <Researcher> for your help and efforts
[15:29] <Kilos> anytime Researcher
[15:30] <pavlushka> Researcher: wow, that's awesome, have a nice family time, :)
[16:37] <Kilos> Researcher https://github.com/ibid/ibid
[16:47] <pavlushka> Researcher: to have an idea on wiki, you can check out https://wiki.ubuntu.com/belkinsa, https://wiki.ubuntu.com/Kilos, https://wiki.ubuntu.com/tsimonq2 and you can search for more , :)
[16:47] <Kilos> lemme just eat then i check it out lad
[16:48] <pavlushka> Kilos: why? I told it to Researcher :p
[16:48] <Kilos> oh thats for researcher
[16:48] <Kilos> im slow man
[16:48] <Kilos> heard the alert bell when my nick was said
[16:48] <pavlushka> Kilos: it happens, even to me
[16:48] <Kilos> haha
[16:49] <pavlushka> hahaha (+1)


[14:22] <astraljava> Should the xfce4-timer-plugin show some kind of icon in the panel?
[15:26] <ochosi> astraljava: no, only a progressbar
[15:36] <astraljava> ochosi: Ok, thanks. There is a dark vertical bar, but I didn't see any progress on it.
[15:37] <ochosi> hmyeah, possible that there are problems with that plugin
[15:37] <ochosi> i've only tested it once
[15:37] <ochosi> are you using greybird?
[15:37] <ochosi> (i thought i fixed that in greybird)
[15:38] <astraljava> I'm using whatever is enabled by default. (sorry, haven't paid much attention to those details yet)
[15:39] <ochosi> well that depends on your version of xubuntu :)
[15:39] <ochosi> anyway, i'm off for now
[15:41] <astraljava> That would be oneiric. :) And yeah, me too, to the gym.
[23:12] <knome> madnick, when would you have time to go through the lightdm/plymouth stuff?
[23:15] <madnick> knome: i am in the process of reinstalling my computer
[23:15] <madnick> with 11.10
[23:15] <knome> okay
[23:15] <madnick> i will have to reset up
[23:15] <knome> would some night next week work for you?
[23:15] <madnick> any time
[23:15] <knome> i was thinking of going to sleep soonish
[23:15] <madnick> next week
[23:15] <knome> okay, i'll ping you
[23:15] <knome> ochosi, what's your schedule?
[23:16] <madnick> well the problem is, i will need to restore the dev environment
[23:16] <madnick> so i cant tonite
[23:16] <knome> yeah, won't be tonight
[23:16] <knome> i'm about to go to sleep
[23:16] <madnick> also wednesday cannot be done for me i wont be home
[23:16] <knome> okay, let me check the work shifts for wife
[23:17] <ochosi> next week == the upcoming week?
[23:17] <knome> err, yeah
[23:17] <knome> 16 ->
[23:17] <knome> weekend would be optimal for me
[23:17] <ochosi> hm, maybe
[23:17] <knome> either saturday or sunday night
[23:17] <ochosi> no, nights/evenings on that weekend are definitely bad
[23:17] <madnick> yes that works for me aswell
[23:17] <knome> awwh :D
[23:18] <ochosi> well you don't necessarily need me :)
[23:18] <knome> true
[23:18] <ochosi> but if i'm there i'll show up
[23:18] <madnick> i'd say for the theme it only needs some more "nice" CSS if we are settled with the general apperance
[23:18] <ochosi> and if you want feedback we can discuss that after your changes
[23:18] <madnick> then we need to figure out the accessability
[23:18] <ochosi> mhm
[23:18] <madnick> and get the wallpaper
[23:19] <ochosi> btw, i recently read that lightdm will now pick a users wallpaper
[23:19] <knome> madnick, let's try to work on it on saturday (21st) night?
[23:19] <madnick> okay
[23:19] <madnick> ochosi: there is functionallity for it in the lib
[23:19] <madnick> but i never tested it
[23:20] <ochosi> mhm
[23:20] <ochosi> i think people might like that
[23:20] <ochosi> making the fade-to-desktop experience after clicking "log in" a bit smoother
[23:20] <madnick> yes
[23:20] <madnick> and also the setting gui for lightdm
[23:20] <ochosi> but anyway, that's just additional stuff, let's fix the other things first
[23:21] <ochosi> yes, the settings gui
[23:21] <ochosi> what was the status on that again?
[23:21] <madnick> wasnt the XFCE project doing something that almost eliminated most of the functionality in that app
[23:21] <madnick> its pretty much done
[23:21] <madnick> its some config file parsing left
[23:21] <ochosi> not sure we'll get any new xfce apps for precise
[23:21] <ochosi> so i think we definitely want your app :)
[23:21] <madnick> okay
[23:22] <knome> yes
[23:22] <madnick> well, ill setup the dev environment tonight
[23:22] <ochosi> iirc the layout of the settings gui was also finalized, right?
[23:22] <madnick> yes i think so
[23:22] <madnick> according to the drafts
[23:22] <ochosi> ok, good, so no more work for me on that ;)
[23:22] <knome> we can go through that on saturday too
[23:23] <knome> i'm sooo willing to get http://status.ubuntu.com/ubuntu-precise/group/topic-precise-flavor-xubuntu.html in better shape ;)
[23:23] <madnick> i couldve uploaded the greeter long ago, i hesitated because i have not been sure about the accessability features
[23:23] <knome> i'd say: upload asap, let's start getting feedback from charlie
[23:24] <madnick> okay
[23:25] <ochosi> +1
[23:26] <knome> and if that means some of the work items should be marked as "done", please update the blueprints
[23:27] <madnick> hehe i will
[23:27] <knome> once we get most of those relating to lightdm/plymouth to "done", we look much better again
[23:45] <knome> okay, see you later
[23:45] <knome> bed calls
[23:45] <knome> ->
[23:48] <madnick> cya


[01:29] <aaii_> needs-help-guy, What you need? :o
[13:57] <andrewbogott> I have this in my cloud-init conf:
[13:57] <andrewbogott> https://www.irccloud.com/pastebin/opt2FxzR/
[13:57] <andrewbogott> nevertheless my ephemeral disk is getting formatted with 'vfat'.  Is there a way I can tell cloud-init to do nothing with the volume rather than (as it seems to be doing now) default behavior?
[14:15] <rharper> andrewbogott: are you on Azure ?  that's the only cloud that I know of that has default configuration for formatting an ephemeral disk;  cloud-init doesn't have default values for those keys, rather they're omitted.  on Azure, there's built-in cloud-config which includes those keys to configure the ephemeral disk.    I think if you set them to something else, like disk_setup: disabled or such; that should replace the built-in
[14:15] <rharper> config when it merges and if the config isn't valid should ignore it.  The default format of azure's ephemeral disk is NTFS formatted.
[14:15] <andrewbogott> openstack
[14:15] <andrewbogott> I will dry 'disabled' for my next test, thanks!
[14:16] <andrewbogott> of course it's also possible that something other than cloud-init is formatting
[14:16] <rharper> ah, let me look at the openstack datasource, it too has some defaults for ephemeral formatting
[14:17] <rharper> oh, IIRC, the openstack metadata service typically includes config for the ephemeral disk as well;
[14:23] <otubo> smoser: quick question on growpart. I've read the whole file but I might be missing something: does this script is self contained? Does it use any other script in the repository?
[14:24] <rharper> the openstack metadata service typically includes a 'block-device-mapping' config which controls this, https://docs.openstack.org/nova/queens/user/block-device-mapping.html ;
[14:26] <rharper> andrewbogott: but, AFAIK, the ephemeral disk is already formatted and mountable;  Azure is the only datasource which *reformats* the disk for linux since it's disk is NTFS formatted by default; so if you're getting VFAT on a disk, I suspect that's the cloud's doing.   if you like, I can examine a  cloud-init.log to see what happened.
[14:27] <andrewbogott> rharper: thanks, I'll check the logs as well
[14:29]  * andrewbogott stops reading cloud-init docs and starts reading openstack docs
[14:38] <otubo> smoser: nevermind, I think I found my problem :-D
[15:24] <smoser> otubo: sorry, iddn't see. i think the answer is yes. it is self contained.
[15:29] <smoser> andrewbogott, rharper  it hink that openstack might present a FAT filesystem based on configuration
[15:30] <andrewbogott> smoser: looks like, although I can't figure out how to configure it so far
[15:30]  * smoser cloning source
[15:30] <smoser> somehow that got big!
[15:32] <rharper> I saw block-device-mapping has a v2 ... which is more interesting ... that'd be nice to support that in cloud-init
[15:33] <rharper> smoser: right,  I suspect this is related to what block service configuration is used ... the classic cinder exposed a disk with ext(something) on it  ...
[15:34] <smoser> https://github.com/openstack/nova/blob/9311f541499f711de064505fab3b24e20451d433/nova/conf/compute.py#L129
[15:36] <smoser> i swear you can configure that on a image basis, but i dont see it.
[15:38] <smoser> maybe you can on launch? in the block device mapping...
[15:38] <smoser>  nova/block_device.py:
[15:38] <smoser> sorry. paste fail
[15:38] <smoser>  https://wiki.openstack.org/wiki/BlockDeviceConfig
[15:40] <rharper> I've done block-device-mapping, but you need to create the storage first (at least in cinder) and then map the cinder device to the VM (at launch or afterwards)
[15:41] <rharper> so maybe something other than cinder creates vfat devices by default
[15:41] <andrewbogott> flavor lets me specify an ephemeral disk size, that's what I'm using. As far as I know it doesn't let me set anything beyond size though...
[15:41] <andrewbogott> I'm thinking 'what to do with ephemeral storage' must be a cloud-wide setting
[15:41] <rharper> yeah, I wouldn't expect any controls; what block device provides ephemeral storage is likely a cloud-level config
[15:41] <rharper> right
[15:42] <andrewbogott> troubling that default_ephemeral_format doesn't even take a 'vfat' setting and yet that's what I'm getting
[15:42] <rharper> one way to test is to allocate a new block device (from whatever block service you have) and attach it to a running instance, and then you can inspect the newly added disk for what fs is on it, etc ...
[15:42] <andrewbogott> I'll try setting it to None and see what it does :)
[15:43] <andrewbogott> Oh, newly created cinder volumes are definitely unformatted
[15:43] <andrewbogott> And I have a bunch of code that supports that behavior (formatting in puppet later on)
[15:43] <rharper> it could be a portability setting ... cross OS filesystem
[15:43] <andrewbogott> so I just want ephmeral volumes to be... also like that
[15:44] <rharper> well, that's counter to ephemeral volumes IIUC, they're always preformatted so they're mountable by default rather than waiting for (or requiring) the OS in the instance to do the work;
[15:44] <andrewbogott> yeah.  It happens that in our cloud we're only using them for this one particular case
[15:45] <andrewbogott> But it might be that 'don't format' isn't supported on the backend, for the reason you just said
[15:48] <rharper> virt_mkfs = []
[15:48] <rharper> (Multi-valued) Name of the mkfs commands for ephemeral device.
[15:48] <rharper> The format is <os_type>=<mkfs command>
[15:48] <rharper> https://docs.openstack.org/ocata/config-reference/compute/config-options.html
[15:49] <rharper> appears to be configurable on the compute side
[15:57] <andrewbogott> you are way ahead of me
[15:57] <andrewbogott> seems like virt_mkfs probably keys off of something else that specifies the format?
[15:57] <andrewbogott> although I can break it on purpose
[15:58] <rharper> looks to me like it's a compute side config value, set on each compute node
[15:59] <rharper> I wonder if the flavor has an OS setting ?
[16:00] <rharper> it's a list of pairs, OS Type -> mkfs.foo ... so some OS value results in a mkfs.vfat ... I'd think that OS Type == Windows, is going to get you a mkfs.vfat .. where as  OS Type == Linux should get you mkfs.ext4 or so ...
[16:06]  * andrewbogott nods
[16:06] <andrewbogott> makes sense
[16:10] <andrewbogott> I'm checking in with the affected user now, they might be happy with it just being ext4 instead of vfat (which is easy to fix, that's just default_ephemeral_format)


[03:27] <pitti> Good morning
[03:30] <thumper> hi pitti
[03:31] <thumper> pitti: happy 10 years
[03:31] <pitti> hey thumper; thanks!
[03:31] <thumper> pitti: I'm nearly at 8
[03:31] <pitti> thumper: crazy how fast that piles up, isn't it?
[03:31] <thumper> uh ha
[03:32] <thumper> my daughters don't really remember me working away from home
[03:32] <thumper> eldest was 5 when I started
[03:45] <thumper> pitti: what are you doing up at 5:30am anyway?
[03:45] <pitti> thumper: getting up and start working :)
[03:46] <pitti> thumper: my wife needs to get up at 4:50, then it depends on how much I can still sleep
[03:46] <pitti> sometimes not any more, sometimes until 6:30
[03:46] <thumper> ugh... too early for me
[03:47] <pitti> took some time for me to get used to it, too
[03:47] <sarnold> careful pitti, at this rate, you'll be getting up before you go to bed..
[03:47] <pitti> heh; but I've been doing this for ~ 3 years now ;)
[03:48] <sarnold> two years back, when I joined, it seemed early, but this seems -super- early, hehe ;)
[03:49] <pitti> sarnold: yeah, certainly not the natural and recommended proper care for a hacker
[03:50] <sarnold> pitti: well, certainly not -this- hacker.. :)
[07:07] <seb128> good morning desktopers
[07:08] <didrocks> morning seb128
[07:08] <seb128> lut didrocks
[07:22] <seb128> robert_ancell, hey, how are you? what are you doing still online? ;-)
[07:22] <robert_ancell> seb128, bug fixing..
[07:22] <seb128> lightdm?
[07:36] <robert_ancell> seb128, yeah
[07:36] <robert_ancell> bug 1364725
[07:40] <seb128> yeah, saw that one in my emails
[07:40] <seb128> robert_ancell, btw Laney is on vac, so don't worry if you don't get much feedback on the gnome-desktop transition this week
[07:40] <seb128> I'm going to try to have a look, but it's not at the top of my list
[07:41] <seb128> would be nice if the Ubuntu GNOME team was helping reviewing/testing since they are the ones that need that upload to land
[07:43] <robert_ancell> :)
[08:10] <darkxst> seb128, robert_ancell, I am planning to take a look at the gnome-desktop branches, but been quite busy this week, will get to it in the next day or 2
[08:11] <seb128> thanks
[08:11] <robert_ancell> darkxst, ta
[08:59] <tkamppeter_> will
[08:59] <tkamppeter_> sorry
[11:23] <ali1234> https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1310788
[11:23] <ali1234> this appears to be another crash caused by unity peeking into application menus
[11:24] <larsu> ali1234: unity shouldn't look into context menus
[11:24] <ali1234> yeah, i know it *shouldn't*
[11:24] <ali1234> but apparently it is
[11:24] <ali1234> https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1363975 seems to be the same crash
[11:24] <ali1234> e.u.c has a backtrace, it is definitely dying inside unity libs
[11:25] <larsu> ali1234: interesting. I'll have a look, thanks for bringing it up
[11:25] <ali1234> thanks
[11:32] <larsu> ali1234: does this happen on trusty for you? I can't seem to reproduce it here
[11:33] <ali1234> no, but then i don't have unity installed
[11:33] <ali1234> it certainly happens for someone somewhere at least once a day so it can't be that hard to reproduce
[11:36] <larsu> sure, I was just trying to find out if this might have been fixed already and just needs a backport
[11:36] <larsu> (also, we do have quite some users. Just because it happens to someone somewhere doesn't mean it's easy to reproduce)
[11:37] <ali1234> thunar doesn't :)
[11:48] <ali1234> i can't reproduce it on a system with only unity and thunar installed
[11:49] <larsu> what else do you need?
[11:50] <ali1234> well the other possibility is xfce desktop while unity is also installed
[11:50] <ali1234> but i don't have a system like that immediately available
[11:51] <larsu> I guess this commit is supposed to fix that: http://bazaar.launchpad.net/~indicator-applet-developers/unity-gtk-module/trunk.14.10/revision/331
[11:52] <ali1234> yes, indeed
[11:52] <larsu> I can't test with a xfce system right now either
[11:53] <larsu> backporting that commit should be easy
[11:54] <ali1234> yeah. of course that doesn't really fix the problem, it just prevents the conditions that trigger it :)
[11:56] <ali1234> it's also possible the user is running thunar in unity and some other condition that we don't have is causing the crash
[11:57] <larsu> ya, backporting would be a first step to make the crash go away
[11:57] <larsu> I'll gladly debug it if you find a way to reproduce this in unity
[11:57] <ali1234> what's more, the error reports stopped on 21st august, so maybe it is already fixed
[11:58] <larsu> and I'll point attente to the problem (he's maintaining u-g-m)
[11:58] <ali1234> thanks. i'll see if we can reproduce it somehow or get more information from the reporter
[12:08] <ali1234> mterry: can we get XDG_CURRENT_DESKTOP in the crash reports please?
[12:08] <mterry> ali1234, hm?  Which crash reports?
[12:08] <ali1234> on errors.ubuntu.com
[12:09] <seb128> seems like you ping the wrong person there?
[12:10] <seb128> that would rather be a question for ev/bdmurray/pitti I would say
[12:10] <ali1234> ah, my mistake
[12:10] <seb128> we do include that info on apport report to launchpad
[12:11] <seb128> so could be a e.u.c side change
[14:07] <Saviq> hi all, having a problem with lightdm here, I'm on a dual-GPU (Optimus) system here, and lightdm just will not start X when I disable Optimus and run with only the nvidia card (proprietary driver)
[14:07] <Saviq> any ideas?
[14:08] <Saviq> I can startx and run the session just fine, it's just lightdm never even tries (no Xorg log or anything, nothing interesting in lightdm log...)
[14:27] <willcooke> Saviq, sounds like that could be a robert_ancell question.  I'll ask him and get back to you (unless someone else knows in the meantime...)
[14:28] <Saviq> willcooke, yeah, I though to bug him, but not around
[14:28] <Saviq> willcooke, thanks
[14:28] <willcooke> Saviq, it's about 2am for him :)
[14:28] <Saviq> I even reinstalled, thought I broke something after having removed nvidia + nouveau due to a hardware issue
[14:28] <Saviq> willcooke, sclacker
[14:28] <Saviq> -c
[14:28] <willcooke> Saviq, I know right!
[14:30] <willcooke> Saviq, I've mailed him
[14:30] <Saviq> willcooke, thanks
[14:44] <seb128> kenvandine, hey
[14:45] <kenvandine> hey seb128
[14:45] <seb128> kenvandine, going to do an u-s-s landing in the next days? ;-)
[14:45] <kenvandine> seb128, yes... been blocked by what's in silo 10
[14:45] <kenvandine> which they are working on landing now
[14:45] <kenvandine> i have a bunch of branches building in silo 20 now
[14:45] <kenvandine> which will need a respin after 10 lands and merges
[14:46] <seb128> k
[14:46] <mvo> seb128: hi, do you know what plans Laney has with the gobject intospection multiarch work? I would love to get it in for 14.10 and I know Laney wants to push it for experimental too
[14:46] <mvo> I'm curious about timeline etc
[14:47] <seb128> mvo, hey, he's on vac until the 11
[14:47] <mvo> oh
[14:47]  * mvo scratches head
[14:47] <seb128> mvo, but he uploaded https://packages.qa.debian.org/g/gobject-introspection/news/20140831T003420Z.html
[14:47] <seb128> he said gir needs rebuilds iirc
[14:47] <seb128> let me look at my irc logs
[14:57] <mvo> seb128: I wonder if I can simply go ahead in ubuntu, ideally prepare it all in a PPA and then mass-copy. but I would need a trusted ppa for that, right?
[14:58] <seb128> mvo, that seems like a transition/something that needs a ffe to me
[14:58] <mvo> seb128: hrm, that not like it was in the old days :P
[14:58]  * mvo files one
[14:59] <seb128> mvo, indeed not!
[15:02] <seb128> mvo, oh, found back the log, http://irclogs.ubuntu.com/2014/09/02/%23ubuntu-desktop.html#t18:09
[15:03] <mvo> seb128: not that much it seems :)
[15:03] <seb128> mvo, no, but basically it's "either take the hit and do the work, or wait for things to be tested in Debian and sync"
[15:03] <seb128> you can probably help in Debian and then sync
[15:06] <mvo> seb128: ok
[15:13] <marga> Trevinho, do you think there's any data that we could provide to help with https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1311316 (input field missing from Unity's lockscreen)?
[15:14] <Trevinho> marga: mh, not sure... I've a workaround in mind but it's probably something due to a race...
[15:14] <marga> Trevinho, I have quite a number of affected users that can reproduce this on a daily basis, so if there's any data to gather, I could do it.
[15:14] <marga> Yes, I agree it's due to a race.  Reports state that it's much more likely to happen when on high load
[15:15] <Trevinho> marga: ah, ok... I'm not getting that for a long time, but if you've some people affected it would be probably nice to give them a debug version through ppa, to understand more
[15:15] <marga> sure
[15:19] <didrocks> fginther: hey, did you received my email about the lost jenkins jobs?
[15:24] <fginther> didrocks, yes, the jobs were accidentally deleted. I have a backup of them, I just need to get them restored after dealing with a few other critical issues
[15:24] <didrocks> fginther: ok thanks! I hope you backed up the version which autologin/add sudoer and so on (for a reminder of what to check)
[15:24] <didrocks> fginther: I'll create the chaining jobs then
[15:25] <fginther> didrocks, yeah, in this case it was just the job configuration that was removed. the VMs should still be there
[15:25] <didrocks> great ;)
[15:25]  * fginther will also check for that
[15:25] <didrocks> thanks a lot!
[15:48] <ara> seb128, any idea why this xserver-xorg upload to trusty-proposed is not being reflected in the pending sru report? (http://people.canonical.com/~ubuntu-archive/pending-sru)
[15:48] <ara> https://launchpad.net/ubuntu/+source/xorg-server/2:1.15.1-0ubuntu2.1
[15:51] <seb128> ara, it is listed?
[15:52] <ara> seb128, no, that's my question. It is not listed in the trusty pending packages, and I don't know why :)
[15:52] <seb128> ara, well, I see it here
[15:52] <ara> seb128, sorry, I see it now, my bad
[15:52] <ara> :(
[15:52] <seb128> want a screenshot of the page?
[15:52] <seb128> ara, no worry ;-)
[15:53] <ara> seb128, thanks, and sorry :)
[15:53] <seb128> nw!
[15:55] <marga> Trevinho, I'm awfully jetlagged and so I'm not sure if I understood you correctly.  Is there a version that would help debugging already available? Are you going to make it available? Do you need anything from me?
[15:55] <Trevinho> marga: I don't have it yet, but we could do it if you have someone that can easily reproduce the issue
[15:58] <marga> I have several someones
[16:53] <kenvandine> seb128_, i have that folks change ready to upload, modified from yesterday based on my chat with bigon_
[16:53] <kenvandine> seb128_, it'll introduce a NEW binary
[16:54] <seb128> kenvandine, k, I'm about to be away but I can new review that a bit later
[16:54] <kenvandine> thx
[16:55] <kenvandine> i'm submitting it to debian too, but can't seem to get reportbug to work
[16:55] <kenvandine> the locking bug...
[17:07] <Laney> mvo: I didn't plan on doing that for 14.10 but was rather going to do it in exp and fix things there as much as possible before next cycle
[17:07] <Laney> is it urgent for you?
[17:08] <bigon_> 18:03 < bigon> kenvandine: didn't you also forgot to move " usr/lib/*/libfolks-dummy.so.*" ?
[17:08] <kenvandine> bigon, i didn't forget it, i left it since it's a lib... simpler to leave it there
[17:08] <kenvandine> it won't load without the backend plugin
[17:11] <bigon> the for libfolks-eds the lib is in the same pkg as the module
[17:11] <bigon> I guess we should follow this here non?
[17:12] <bigon> need to go now
[17:12] <kenvandine> bigon, ok, i'll do that
[17:28] <mvo> Laney: aha, ok. not really urgent, it would be nice as it would unblock ubuntu-sdk-libs:$arch but I just checked the rdepends and the amount if quite substantial, so I guess utopic is a bit too ambitious
[17:33] <mvo> Laney: I will play around a bit in a ppa and see how bad it is (or have you prepared stuff already?)
[20:06] <robert_ancell> Saviq, are you getting bug 1305006?
[21:03] <Saviq> robert_ancell, reading
[21:05] <Saviq> robert_ancell, I don't *think* it was crashing, let me find out again
[21:05] <robert_ancell> Saviq, do you have the lightdm.log?
[21:20] <Saviq> robert_ancell, no, no crash, this is all that's left in /var/crash; /var/log after a "initctl start lightdm" with no X ever started http://paste.ubuntu.com/8226876/
[21:20] <Saviq> robert_ancell, and I'm trying to run a standard ubuntu desktop session, no unity8 involved
[21:21] <robert_ancell> Saviq, oh interesting. What does "loginctl list-seats" give you?
[21:21] <Saviq> robert_ancell, seat0
[21:22] <robert_ancell> Because LightDM appears to think there are no seats
[21:22] <Saviq> robert_ancell, but I'm running a session through "startx" now, let me log into IRC from somewhere else
[21:22] <Saviq> brb
[21:22] <robert_ancell> And "loginctl show-seat seat0"
[21:24] <Saviq_> robert_ancell:ok, here from another pc, loginctl says seat0, 1 seats, no greeter
[21:25] <robert_ancell> I want to check if seat0 has CanGraphical=false
[21:26] <Saviq_> robert_ancell:CanGraphical=no
[21:26] <robert_ancell> That's the issue. Why does it think that?
[21:26] <Saviq_> you tell me :)
[21:27] <robert_ancell> Can you file a bug with this info an we'll try and dig into loginds logic to determine what's going on
[21:28] <robert_ancell> I suspect that disabling Optimus is making logind think there's no video card
[21:30] <Saviq_> robert_ancell:this has worked for me Fri morning, btw
[21:31] <Saviq_> except I'm on a different mobo now, different BIOS, wonder if that affects things
[21:31] <robert_ancell> Saviq_, yeah, we changed to honoring what logind specifies, so before we just ignored CanGraphical as startx will also
[21:31] <Saviq_> ah, nice coincidence... could've saved me a reinstall this morning :)
[21:33] <robert_ancell> Yeah, sorry. Was busy sleeping at 2am :P
[21:33] <Saviq_> robert_ancell:yeah, we already decided with willcooke you're a slacker
[21:33] <Saviq_> bug #1365165
[21:34] <robert_ancell> Lucky we have such little overlap he's calmed down before I next see him and he doesn't fire me
[21:34] <robert_ancell> Saviq_, ta
[21:34] <Saviq_> robert_ancell:let me know if I can get you anything else, I'll try downgrading lightdm then
[21:35] <robert_ancell> Saviq_, you should be safe with lightdm <= 1.11.7. I'll start digging into how logind does the CanGraphical determination - currently have no knowledge there
[21:35] <Saviq_> robert_ancell:good enough, thanks a bunch
[21:40] <robert_ancell> Saviq_, can you add a lspci to the bug report?
[21:47] <Saviq_> robert_ancell:will do
[21:52] <Saviq> robert_ancell, and yeah, downgraded lightdm works like a charm, thanks!
[21:53]  * Saviq missed his second screen
[21:55] <Saviq> robert_ancell, lspci uploaded
[21:55] <robert_ancell> Saviq, ta
[21:58] <robert_ancell> Your system is different to mine. Mine shows both an Intel and NVIDIA VGA controller on the PCI bus. Yours only seems to have NVIDIA
[21:58] <robert_ancell> But you must have an Intel controller somewhere
[21:59] <robert_ancell> RAOF, ^ any insights into Optimus and where the Intel controller would be?
[22:24] <RAOF> Saviq: When you say “disable optimus” what do you mean? Do you mean flick a bios switch to “nvidia only” or somesuch?
[22:39] <Saviq> RAOF, yes
[22:39] <Saviq> RAOF, it literally says "Enable Optimus" and a checkbox
[22:39] <Saviq> robert_ancell, ↑
[22:40] <Saviq> robert_ancell, I explicitly disable the intel one in the BIOS to be able to use external monitors properly, otherwise I end up in hybrid/prime and stuff's not so great
[22:40] <RAOF> You're using the binary nvidia drivers like all the UI heathens, aren't you?
[22:41] <Saviq> RAOF, not for long now ;)
[22:42] <Saviq> RAOF, but yeah, nouveau just doesn't cut it, and with intel alone I only get the VGA out
[22:42] <RAOF> I just wonder whether this bug is actually “logind doesn't understand that non-kms drivers can run X”.
[22:42] <Saviq> and with hybrid all hell breaks loose with multimonitor
[22:43] <RAOF> tselliot would be interested in your hybrid experiences, methinks.
[22:44] <RAOF> On the basis that he's been doing much of the “can we make hybrid work” bits.
[22:45] <robert_ancell> RAOF, yeah, that's what I was thinking
[22:45] <robert_ancell> Is that solvable?
[22:46] <RAOF> Not really, no.
[22:47] <RAOF> logind can't know if X will run without actually running X.
[22:47] <RAOF> Which makes me wonder what CanGraphical is meant to be.
[22:47] <robert_ancell> yeah
[22:47] <robert_ancell> CanGraphical means "has a graphical device associated with this seat:
[22:47] <robert_ancell> "
[22:48] <RAOF> Yeah, it's a barefaced lie.
[22:48] <robert_ancell> RAOF, is there an alternative method of telling if a binary driver device is present, i.e. can we just patch logind?
[22:48] <RAOF> Well, it *could* do that correctly, I guess. By doing pci/usb/whatever probing equivalent to what X does...
[22:49] <RAOF> Saviq: Hey, could you dump “udevadm info --export-db” output on that bug?
[22:50] <Saviq> RAOF, done
[22:51] <RAOF> robert_ancell: We could, assuming that we have udev rules that appropriately tag all possible output devices with seats, and then logind can *distinguish* all possible output devices...
[22:52] <robert_ancell> RAOF, so it might just be a missing udev rule?
[22:52] <RAOF> Plausibly.
[22:55] <RAOF> So, I'm not sure what logind checks, but Saviq's udev output shows that there's nothing with an appropriate seat tag.
[22:56] <robert_ancell> RAOF, but there is a device that could/should be tagged?
[22:56] <robert_ancell> i.e. udev at least knows about the device
[22:57] <RAOF> Not sure. There's both a drm device and P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0 with DRIVER=nvidia, so at least in this case there's options.
[22:58] <RAOF> But I'm not sure if logind is (for example) looking for a framebuffer or something.