[06:32] good morning === amithkk is now known as Guest39143 === tkamppeter_ is now known as tkamppeter [07:34] Good morning [07:35] Bonjour [07:37] bonjour pitti! c'est à ton tour de te lever tard ;) [07:38] didrocks: oui, je ne suis pas très bien [07:38] seems my cold came back, after I was already over it [07:40] good morning! [07:40] argh, take care pitti :/ [07:40] hey larsu! how are you? [07:40] didrocks, good thanks, and you? [07:40] hey larsu! [07:40] pitti, hi, gute Besserung! [07:41] larsu: I'm fine, thanks! [07:41] is there a reason that `update-manager -d` doesn't work? [07:41] * larsu wants to finally update to R [07:43] larsu: do you have pending updates? [07:43] mvo, no [07:43] larsu: hm, does do-release-upgrade -d work? [07:43] oh, hey mvo, happy new year! [07:44] hey pitti, happy new year! [07:44] mvo, seems to work, thanks! [07:45] and happy new year ;) [07:45] cool [07:45] and happy new year larsu [07:45] thanks :) [07:52] hey mvo! happy new year :-) [08:15] RAOF: hey Chris, how are you? [08:15] pitti: Yo! [08:16] pitti: I'm within one standard deviation of my long-term average :) [08:16] haha [08:16] RAOF: happy new year then! [08:17] pitti: And to you, likewise! [08:17] RAOF: and may your health not deviate more than 1.5σ from the expected value :) [08:18] RAOF: so I wanted to ask you, do you know how and where X.org detects monitors? [08:18] RAOF: I already checked the X.org server itself and its xrandr extension; that doesn't just seem to read sysfs or so; it seems that's the responsibility of the individual device drivers? [08:19] RAOF: background is, I want to see whether and to which degree we can simulate monitors in a mock environment, for writing tsts [08:19] and tests, too [08:19] The drivers we care about query the kernel. [08:19] so I was hoping it would just read syfs, but it doesn't [08:19] Mocking that out is going to require mocking libdrm [08:20] Specifically the handful of ioctls dealing with modesetting. [08:20] ah, so they are directly poking the hardware, not reading /sys/class/drm ? [08:20] Correct. [08:21] RAOF: intercepting ioctls is already on my table [08:21] You can quirk an edid by writing to the firmware-ish file, but that's not going to help if the output is not detected as connected, or if you want to fake, say, an HDMI output. [08:21] xvfb doesn't seem to have xrandr capability, so I guess we need to start the real X.org under some kind of dummy driver [08:22] RAOF: so I guess as we have to use a dummy driver anyway, that one coudl just report a set of fake monitors? [08:22] Absolutely. [08:23] That'd be a simple extension to xf86-video-dummy [08:23] right, that woudl have been my next question; is xserver-xorg-video-dummy the right driver for this kind of thing? [08:23] ¹: For sufficiently boring boilerplaity values of “simple” [08:24] I would think so, yes; it's pretty much what you're after - a no-hardware fake graphics driver. [08:25] do you know if that's sufficiently capable to run unity on? [08:27] RAOF: ok, thanks so far; I'll play around with this, see how to start X.org with the dummy driver, and where to plug in RR bits [08:27] pitti: Funny, I looked into this just last night. What specifically are you wanting to test? [08:27] If unity can run with software rendering it can run on dummy. [08:28] RAOF: oh, another question -- how does X.org detect the driver to use? [08:28] Magic! [08:29] soren: I have no specific test right now; I want to evaluate how we can set up various "multiple monitor" scenarios and then test xrandr and unity within that [08:29] pitti: It's got a pciid→driver switch statement buried in the bowels of it. [08:29] RAOF: right, I meant, does it again do its own hardware poking, or just iterate through /sys or /proc? [08:30] It uses libpcithingamabob; I think that does /sys probing, from memory. [08:30] ah, libpciaccess0 [08:30] pitti: This *might* be superceded by the udev code, new in 1.13 (or 1.12); I've not looked at the driver matching code since that landed. [08:30] pitti: Yeah, that one. [08:30] splendid, thanks [08:31] we can easily mock bits in /sys [08:31] soren: so what did you look at? starting X.org with the dummy driver? [08:31] RAOF: thanks for your help! [08:31] pitti: Ok, I can't help much then. I was looking at slightly higher layers, but if you wat to be able to test xrandr itself, that's a different story. [08:32] hey desktopers [08:32] it's a seb! [08:32] bonjour mon ami [08:32] salut seb128 [08:33] pitti: I was looking into adding some automatic monitor switching magic to XFCE and wondered how I could test it. [08:33] soren: doesn't that also require faking monitors? [08:33] pitti: Gnome has its own abstraction for it, which should be easily mockable if you just want to test the unity bits. [08:33] in libgnome-desktop, yes [08:34] Right. [08:34] pitti, hey, how are you? [08:34] didrocks, lut ;-) [08:34] seb128: my cold bounced back, so could be better, but ok for now [08:35] how are you? [08:35] I'm good thanks [08:35] soren: I thought that would just be a rather straight interface to xrandr [08:35] pitti: I didn't actually write any code. I just looked at what it would take. I think I'd just have faked the "something changed" event and checked that it used the correct, new config. In unit tests, that is. I suspect you're doing something more integration test-ish? [08:35] soren: i. e. no file interface in between which you could intercept? [08:35] soren: ah, ok [08:36] pitti: Both Gnome and XFCE uses the xrandr library. I suppose xrandr must as well. Perhaps that's easier to deal with? [08:36] soren: yeah, ideally we could start an X server (with -dummy or even xvfb, but that doesn't seem to work), run unity or gnome-shell or whatever in it, then change the mocked monitors, and verify that it adjusts accordingly [08:37] soren: that's the bit I'm currently investigating :) [08:37] soren: everything that uses /sys properly to detect hardware is easy to mock [08:37] everything that does its own probing with poking ports and ioctls is much harder, of course [08:38] but I guess X.org needs to work on more systems than just linux [08:38] pitti: Oh, what I meant was a mock implementation of libxrandr itself, not the primitives that xrandr uses/manipulates. [08:38] ah [08:38] pitti: I don't know if that'll be more or less work, really. I'm just throwing the idea out there. [08:39] soren: well, xrandr itself is pretty shallow [08:39] soren: it's little more than poking commands into the X socket [08:39] the actual detection and implementation of the commands happens on the driver side [08:39] (shallow from the mocking perspective, not from the logic, of cours) [08:40] Do you mean libxrandr? Or /usr/bin/xrandr ? [08:40] both really [08:40] on the client side, xrandr has no hardware specific bits [08:40] Right. [08:41] it just talks to the X socket, no to sysfs, ioctls, etc. [08:41] Right. [08:42] This seems like a good place to hook in to me. [08:42] ..but you naturally understand much better what it is that you want to test. :) [08:43] That saves you completely from having to think about hardware. I like to not think about hardware :) [08:43] indeed intercepting it at the X protocol level would be a lot simpler [08:44] I'm not actually interested in the sever-side layers; mostly in that applications and the desktop DTRT in various multiple-monitor scenarios [09:01] good morning everyone [09:02] hey [09:04] hey didrocks, happy new year to you as well! [09:04] thanks ;) [09:05] hey chrisccoulson, Laney [09:05] hey didrocks, Laney, how are you? [09:05] hi mvo, happy new year :) [09:05] striving away [09:05] chrisccoulson: good good! yourself? :-) [09:05] chrisccoulson: regular ping about my thunderbird stalling issue btw :p [09:06] hey chrisccoulson! happy new year to you as well :) [09:06] didrocks, tired. both daughters decided that they were far too cool to sleep last night [09:07] hey chrisccoulson, Laney [09:07] mvo, oh, a mvo! happy new year! [09:07] * seb128 hugs mvo [09:07] mvo, how are you? [09:07] chrisccoulson: argh ;) [09:07] seb128: !!! happy new year [09:07] * mvo hugs seb128 [09:08] seb128: I'm good, thanks, all very new, like I get up at 6 in the morning and commute to a office, a really strange experience. but I can hack on the train, so thats great [09:08] mvo: how far are you from the university? [09:09] mvo, 6, man ... I decided to try to start working at reasonable time and be at the computer at 9am so I wake up between 8 and 9 and I already find that difficult :p [09:09] didrocks: its about ~35min by train plus a short bus trip [09:09] seems reasonable :) [09:09] seb128: haha [09:09] didrocks: yeah, its not too bad [09:09] didrocks: but quite a change [09:09] yeah, I can imagine :) [09:10] seeing /real people/! [09:10] Laney: do they exist? I keep hearing from that, but never conducted that to facts [09:10] Laney: yes! out of my cave. I wasn't aware of how many people there are actually in the real -world ;) [09:11] didrocks: I have empiric evidence of that now! at least here in my part of the world they do exist :) [09:11] 10:05:56 didrocks | chrisccoulson: regular ping about my thunderbird stalling issue btw :p [09:11] chrisccoulson: I think you missed it ^ [09:11] mvo, see, they were right when they put you in the "dog" category back then (was it in plymouth?) ... you like people after all ;-) [09:11] mvo: waow! amazing :-) [09:11] should be a German-only thing. I refuse to believe it! :-) [09:12] didrocks, yeah, i've not looked at any thunderbird stuff since i got back ;) [09:12] (thanks to firefox bugs) [09:12] seb128: lol [09:12] seb128: indeed, I think that was around the plymouth time - the funny thing is that my first thought about plymouth was the bootscreen, not the conference we had there :P [09:13] mvo, i don't believe real people exist. you must provide evidence :) [09:13] they're the people that bring my internet shopping deliveries, right? [09:13] actually, i think i saw a person walk past my window one day [09:14] chrisccoulson: haha, I can take pictures from the cafeteria - there are two kinds, man *and* woman [09:14] Laney: lol [09:16] mvo, lol, same here, I had to check on google if that spelling for the city was the same :p [09:21] unity is crashing btw on my dual monitor fglrx setup :P but I will look into that later, gtg [10:07] RAOF: hm, is there a replacement for -nohwaccess ? (https://wiki.ubuntu.com/X/Rootless) [10:10] RAOF: nevermind, apparently not needed with using the dummy driver [10:26] didrocks: do you happen to know whether it's possible to run two unitys at the same time as an user/ [10:26] didrocks: I tried "DISPLAY=:1 dbus-launch unity", and while that works, that still kills/restarts my "main" unity [10:26] pitti: hum, I doubt it, first compiz is checking there is no other window compositor running [10:26] DISPLAY=:1 compiz seems to work fine [10:26] didrocks: well, my real session is on display :0 [10:26] ah, another DISPLAY [10:26] I tried the dbus-launch, but that doesn't seem to help either [10:27] you have some services that you will need to dbus-launch as well [10:27] but that shouldn't kill as it happens for you here [10:28] Window currentWmSnOwner = XGetSelectionOwner (dpy, wmSnAtom); [10:28] this is the detection of the other compiz running [10:29] it seems to be per dpy [10:29] pitti: do you know if at least, compiz is trying to load its plugin? [10:29] didrocks: they actually do run in parallel, just that the original compiz restarts [10:29] didrocks: yes, that all seems to work fine [10:29] pitti: well, unity is running --replace by default [10:29] DISPLAY=:1 compiz [10:29] flawless even with the same dbus [10:30] even ok, so it's really unity, I don't see any reason off hand [10:30] didrocks: ok, nevermind; not a biggie for now [10:30] but as you are stealing the unity-panel-service dbus connection, maybe that impact [10:30] (it's dbus activated, so you need 2 of them) [10:30] that was my first guess, but with dbus-launch it has its own private bus [10:31] oh right, so you have a second one running spawn by the second bus [10:31] hum [10:31] anyway, my main exercise was to run unity under an user X.org with the dummy driver, which seems to work [10:31] sweet :) [10:32] I'll try to do a screenshot [10:32] that would be interesting :) [10:38] awesome, that works nicely === vrruiz_ is now known as rvr_ === cking_ is now known as cking [10:56] Laney: do you want to have a look at https://code.launchpad.net/~logan/ubuntu/raring/gst-plugins-good1.0/debian-merge/+merge/141136? [10:57] as you won the privilege to be the gst maintainer :) [10:57] * Laney screams [10:57] yeah, sure :P [10:57] Laney: webkit, gst, what would be next? :p [10:57] will* [10:57] thanks Laney ;) [10:58] desrt: hey you about ? [10:59] desrt: I'm generating an introspection binary and it hangs on my_thing_get_type () inside of g_once_init_enter, was wondering if there's an obvious solution that I missed [11:01] seb128, is it possible to upload devhelp 3.6.1 in quantal? [11:01] seb128, it fix an annoying bug that I cannot do ctr-c to copy text [11:02] IIRC that's the only fix in .1 release [11:02] xclaesse, you pinged me about that in december [11:02] xclaesse, I got it uploaded: https://launchpad.net/ubuntu/+source/devhelp/3.6.1-0ubuntu0.1 [11:02] xclaesse, it didn't go from proposed to updates because nobody confirmed that the bug is fixed, if you want to do it please comment on https://bugs.launchpad.net/ubuntu/+source/devhelp/+bug/1079694 [11:02] Launchpad bug 1079694 in devhelp (Ubuntu Quantal) "3.6.1 stable update, fix ctrl-C copy" [Low,Fix committed] [11:03] seb128, ahhh, ok. I though you forgot about it :) [11:03] xclaesse, ;-) [11:03] seb128, ok I'll test that right now [11:03] xclaesse, just enable quantal-proposed and get it from there [11:04] xclaesse, thanks [11:14] seb128, cannot get to software source settings [11:14] it does nothing when I click on it [11:15] seb128, I tried to just dpkg -i the deb from https://launchpad.net/ubuntu/+source/devhelp/3.6.1-0ubuntu0.1/+build/4024122 but it's missing -common package [11:21] seb128, http://pastebin.com/qbD1ALKD [11:21] python3.... === vrruiz_ is now known as rvr_ === vrruiz_ is now known as rvr_ === MacSlow is now known as MacSlow|lunch === francisco is now known as Guest79688 [12:20] * Laney requests the Archive Gods consider promotion of farstream-0.2 [12:20] requires gstreamer1.0-nice too [12:59] I wonder if anyone has tested grilo yet? related to bug #1035701 [12:59] Launchpad bug 1035701 in totem (Ubuntu) "grilo plugins should be enabled in Totem" [Undecided,Triaged] https://launchpad.net/bugs/1035701 [12:59] I've found myself missing UPnP/DLNA support [13:00] just a mental note partly to myself... === Guest39143 is now known as amithkk [13:21] requesting a new merge of cairo, with the egl backend enabled [13:22] it's been enabled on debian all the time, no mention on the changelog why it's disabled on ubuntu [13:22] weston would like to have it [13:23] ok, ricotz explained why :) [13:25] * Sweetshark is churning away on precise patches ... [13:26] Laney, hi [13:27] Laney, while you were looking into enabling wayland-backend, would it be much trouble if you add --enable-broadway-backend too (gdk lib size will increase by like 90kb) === mterry_ is now known as mterry [13:28] Laney, be aware of the backend default choice which might need to be patch in 3.6.x [13:35] attente, good morning [13:35] larsu, hi [13:35] attente, I can't reproduce your crash :) [13:35] but I do get the same warning about the handler id [13:36] anything specific I need to do to trigger it? [13:36] the warning itself is the crash [13:36] totally kills it for me [13:36] interesting. Are you running with G_DEBUG=fatal-warnings or something? [13:36] it just continues running for me [13:37] do the menus work for you? [13:37] yes, except for the emoticon menu [13:37] I guess because they are custom widgets? === MacSlow|lunch is now known as MacSlow [13:37] probably [13:39] actually the menu works, but the images aren't displayed [13:40] is there a G_MENU_ATTRIBUTE for menu item images? [13:40] not upstream, no. We've been using x-canonical-icon for the indicators, but that probably doesn't work yet for the appmenu [13:41] by the way: what are you patching in indicator-appmenu? [13:41] it's just an extra action group with the "unity." namespace [13:41] ah, good idea [13:41] so that we don't have to go through the trouble of grabbing the old action group and merging it into ours [13:42] makes sense. And the action names are simply the labels of the menu items? [13:42] all desrt's idea [13:42] in general, yes [13:42] but if a GtkAction is available, we use that instead [13:43] wow, this thing is much cleverer than I thought :) [13:43] hm, that warning appears (twice) when I receive a message. But not every time... [13:44] haha, it's been in the works for a long time now, so i would hope so... [13:45] anyways, i'm still trying to fix the package again... [14:09] * Sweetshark is down to 5 patches for precise backports. [14:19] seb128 heya, sorry for the delay. done - https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1026442 [14:19] Launchpad bug 1026442 in pidgin (Ubuntu) "Buddy pounce - send message window too short" [Low,Confirmed] === huats_ is now known as huats === m_conley_away is now known as m_conley [14:37] y [14:37] whoops :) [14:41] ritz, hey, ok, thanks [14:41] attente, hey, need packaging help there? [14:42] seb128, things seem to be working fine here, but thanks :) [14:43] great, well done! [14:43] attente, this bug is super tricky :-/ [14:43] seb128 is it fine if I post the SRU notes to priv lp [14:43] or this has to be to pub lp [14:44] empathy does some crazy stuff with that menu (it's the Contact menu), but it appears like it's nothing illegal :) [14:44] larsu yeah... don't worry about it too much... [14:44] larsu: what is it doing exactly? [14:44] ritz, better public, otherwise the SRU team and the verification team will not be able to read those [14:45] okay, cool [14:46] attente, it sets the submenu for the contact, a qdata (that it doesn't seem to use) and connects to notify::visible for no apparent reason [14:46] attente, http://git.gnome.org/browse/empathy/tree/src/empathy-chat-window.c#n603 [14:47] attente, I tried creating the same circumstances from a test script, but didn't manage to get the same warning [14:50] larsu, your test script also switches the submenu? [14:50] attente, yes [14:50] huh. [14:51] hello there [14:51] anyone know what the status of the LibreOffice ppa is? [14:52] it looks like 3.6.1-rc2 never got built, and hasn't been updated since [14:52] https://launchpad.net/~libreoffice/+archive/ppa?field.series_filter=precise [14:54] gQuigs, hey, check with Sweetshark, he's maintaining libreoffice for Ubuntu [14:54] thanks seb128, ping Sweetshark [14:55] pong [14:55] gQuigs: you have 5 minutes, then Ill be in a TDF board of directors call [14:55] ;) [14:56] eh, tricky. first writing the content, then the ping. [14:56] thanks Sweetshark, I was just wondering what the status of the PPA is?.. it looks like 3.6.1-rc2 failed in someway [14:58] yes, it seems ricotz did that. I asked him to always build in a separate ppa, but IIRC he ignored that here because it was the first 3.6 upload. [14:58] still would have been better [14:59] * Sweetshark checks the buildlog [15:00] seems like there are deps missing on precise. for the specific one a first workaround would be to disable the mediawiki extenion to be build. [15:01] gQuigs: https://launchpad.net/~bdcomp <- he is currently working on backporting LO to precise, but he still has a lot to learn, so it still might take a while. [15:01] anyway: gone for now, call ;) [15:02] Sweetshark: thanks! [15:04] fscking timezone, was off the mark by one hour. anyway, I think you got what you needed for a start ;) [15:06] gQuigs: https://launchpad.net/~bdcomp/+archive/backports/+packages <- there is a package building in there. note the big, fat "DO NOT USE IT" on the ppa though ;) [15:07] I did notice that... :) [15:09] attente, something tries to disconnect the handler twice. This might mean we have a circular menu structure somewhere... [15:09] ok [15:10] but the handler is on the UnityGtkMenuShell, right? [15:10] not the GtkMenuShell, i believe [15:11] er... sorry [15:11] yes, UnityGtkMenuShell is the GMenuModel, right? [15:11] right, but actually the exported version of that [15:11] yes [15:13] i'm just fixing that non-portable linking warning right now [15:13] attente, actually, the handler is on a UnityGtkMenuSection [15:14] oh, wait, I think I'm mistaken: the handler isn't disconnected twice [15:14] I got confused by dual debug printfs :) [15:14] hehe [15:22] attente, so its much easier than this... just a object_unref too many. The question is: where? :P [15:23] larsu, could it just be that the section is disappearing without the disconnect code knowing about it? [15:24] attente, well, the disconnect code has a reference on it, so it shouldn't disappear [15:24] but it definitely does, I put a weak ref on it [15:24] :S [15:24] ya [15:24] :) [15:24] ok, haha, thanks :) [15:39] attente, got it. [15:39] phew [15:39] seb128 / didrocks: Direct ping regarding the ^^^ promotion request ;-) farstream-0.2 (source) and gstreamer1.0-nice (binary from source already in main) [15:39] if you have time [15:39] larsu: what was it? [15:39] Laney, didrocks: can do [15:39] looking [15:39] merci [15:39] de rien, sorry for missing it earlier [15:39] thanks seb128 :) [15:39] yw ;-) [15:40] attente, http://paste.ubuntu.com/1513350/ [15:40] ah wait, that's your own function [15:41] Your log says "Run dispose to break cycles." [15:41] Laney, done [15:41] great [15:42] will upload empathy when that publishes then [15:42] attente, I'm pretty sure you shouldn't call g_object_run_dispose in this case [15:42] but it's a question for desrt, really [15:42] do you remember which problem this solved? [15:43] larsu, i added that to break the ref cycle between shell and section when the section disappears [15:43] or is supposed to disappear [15:44] hm, I'm not sure I know enough about your code to give good advice here :) [15:44] but i thought the problem was that g_object_unref was getting called too many times [15:45] but if the fix works, you're probably right [15:50] attente, hm. I'm not sure I fully understand it yet [15:50] (after what you just said) [15:50] actually, i'm having a hard time understanding why it would fix the problem too... [15:55] smspillaz: using only DEFINE_TYPE macros? [15:55] smspillaz: doing anything odd from class_init() functions? [15:55] if you're using the stock get_type() from G_DEFINE_TYPE then the usual cause of this is that you're doing something bad in some sort of class_init [15:56] desrt, are weak refs notified on dispose? [15:56] otherwise, it could be an obscure race that I know we have in multi-threaded situations... would be strange to see that in the go-i scanner, though [15:56] unless, as above, you're calling weird stuff from class_init() :) [15:56] desrt, as in, if attente calls g_object_dispose manually, will weak refs be notified? [15:56] larsu: yes and no [15:56] larsu: no. [15:56] but they are notified before dispose() is called automatically after the last ref drops [15:56] I have a stack trace that looks like it [15:56] hm, weird [15:56] well [15:57] dispose() often results in the handler calling unref() on a lot of stuff [15:57] which in turn could obviously cause a weak notify [15:57] yeah but it's on the same object [15:57] hmm [15:57] odd [15:57] cycles? [15:58] i doubt it [15:58] read the trace... [15:58] then read the source :) [15:58] ya [15:59] desrt, in any case, running dispose manually is probably not a good idea, is it? [15:59] I mean, what if other objects still have references... [15:59] in my opinion dispose is completely stupid [15:59] I know [15:59] but that doesn't answer my question :) [16:03] running dispose is supposed to be an idempotent operation, right? [16:03] yes [16:11] desrt, want to meet an old friend for lunch today? [16:12] is he swiss? [16:12] no, that's on the 19th, btw [16:12] cool :) [16:13] i'm probably up for it as long as the location is reasonable [16:13] although it would probably be nice to know who it is first [16:13] mehdi [16:13] king and bay [16:13] for sure [16:13] 12:30 [16:13] sorry about the short notice [16:13] i still have a sworn pact to murder the two of you for what you did to the se3f03 course webpage [16:14] hahah [16:14] it will be very convenient to see both of you in one spot === pitti is now known as sabdfl [16:21] well... this is an interesting development === sabdfl is now known as pitti [16:33] seb128, didrocks: hey, just replied on bug #1047606 ; do i need to fix and attach new files to the bug, or wait until it's accepted and just upload a new revision? [16:33] Launchpad bug 1047606 in Ubuntu Raring "[needs-packaging] ubuntuone-client-data" [Wishlist,New] https://launchpad.net/bugs/1047606 === amithkk is now known as mechanobot [16:38] dobey, new revision will do [16:49] attente, sorry, I was distracted for a bit, but I have the real solution [16:49] for which I had to go into gobject.c [16:49] not nice [16:50] what is it? [16:50] so g_object_dispose calls g_signal_handlers_destroy [16:50] pretty simple :) [16:51] I think the real fix here is to not call dispose. If you're worried about cyclic references, use a weak ref on one side [16:52]