[00:05] jasoncwarner: ping [00:05] hey [00:46] patrickmw, hey [00:46] robert_ancell: hello [00:47] patrickmw, about your evolution bug, do you want to do the patch? [00:47] it's on the master branch, and needs to be backported to 2.32 [00:47] robert_ancell: i would actually [00:48] ok, so do you have a checkout of the evolution source? [00:48] not currently. I can do that [00:49] have you used quilt before? [00:49] grrr haven't built i386 packages with sbuild for ages, and now I find it desn't just work when using an i386 chroot on an amd64 machine. [00:49] robert_ancell: i have not [00:49] ok, this isn't going to be pretty :) [00:49] robert_ancell: haha [00:49] so, first step is to debcheckout evolution [00:50] you get to learn all the grottyness of debian packaging today :) [00:54] robert_ancell: sorry, had to install subversion [00:54] robert_ancell: ok got the source [00:55] patrickmw, ok, cd to the directory and export QUILT_PATCHES=debian/patches [00:55] robert_ancell: var set [00:56] quilt pop -a [00:56] done [00:57] get the patch, and copy it into debian patches using the naming convention that is there [00:57] I get the patch from the web git interface http://git.gnome.org/browse/evolution/commit/?id=7215cf088f73cfa61e877a83fa0fdd4227095725 [00:57] add the patch into debian/patches/series [00:59] (for reference here is the complete documentation https://wiki.ubuntu.com/PackagingGuide/Complete) [01:03] robert_ancell: ok [01:03] then reapply patches with quilt push -a [01:04] (I don't think you had to unapply them come to think of it, just me being paranoid) [01:04] the new patch may not apply, see if there are any errors [01:05] patrickmw, hang on, did the evolution source come from svn? Are you running natty? [01:06] robert_ancell: source came from svn, running maverick [01:06] patrickmw, ah, you'll have the maverick source then. Do you have a natty vm? [01:06] robert_ancell: yes [01:06] ok, need to do it in that [01:08] Follow these instructions http://paste.ubuntu.com/570863/ [01:09] patrickmw, ^ [01:09] robert_ancell: debcheckout is wrong then? [01:09] patrickmw, yes, sorry. [01:10] robert_ancell: np, thanks. [01:10] That checks out the packaging branch, but that wont have any source so you can't edit the patch [01:10] however at the end of this you'll have to make the change on the packaging branch [01:10] if i shoehorn linux-image-generic and xserver-xorg (plus requisite dependencies) from natty into a maverick image, should it work? [01:10] right now the background and cursor get drawn, but windows don't [01:10] (and the cursor changes as would be expected if there were windows under it) [01:11] patrickmw, There is a new process called Ubuntu Distributed Development (UDD) that we are working towards which will have it all in the same branch and a lot easier [01:11] this is an...incredibly stripped down image, so it's possible that i've removed a package i actually need, but just wanted to ask before i go digging [01:12] i guess it's probably worth doing a normal maverick install and seeing what falls out [01:14] broder, sorry, not sure, but sounds dangerous :) [01:28] aha. there's a bunch of "intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Invalid argument" in Xorg.log [01:28] what is TryExec for in .desktop files? [01:29] kklimonda: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html [01:29] broder: Sounds like our friend the OOM bug. [01:30] ah, excellent [01:30] i'm not out of memory, though [01:30] broder: hmm.. it looks like in natty TryExec is used instead of Exec to actually launch the application? [01:31] But I don't have all the context, so I might be wrong. [01:31] RAOF: what sort of additional context would be useful to you? [01:31] Any bit before there's a bunch of "intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Invalid argument" in Xorg.log, which was the first thing I got after I rejoined :) [01:32] sure. i'm attempting to shoehorn natty's kernel + X stack into a maverick image, which happens to be using casper [01:32] robert_ancell: after running quilt -f .rej files were created but each patch "applied". does that mean there are still conflicts to edit manually? [01:32] RAOF: the background and cursor render, but windows don't [01:32] patrickmw, yes [01:32] RAOF: but the cursor does change, and in a way that's consistent with there being windows under it [01:33] RAOF: using -intel [01:33] chrisccoulson: does Firefox by any chance use TryExec to launch the application from the Opening dialog? [01:34] chrisccoulson: when I change TryExec=transmission-gtk to TryExec=transmission-gtk %F in the desktop file I can once again launch torrents from Firefox without using the Downloads dialog [01:34] broder: Interesting. Could I get the full Xorg.0.log? [01:34] robert_ancell: ok, i think i got it [01:38] RAOF: http://pastebin.com/aancMWaf [01:38] RAOF: the other caveat is that this is an image i use at work, and is stripped down beyond all belief, so it wouldn't surprise me at all if something critical was missing [01:39] Hm. Got an accompanying dmesg? [01:40] http://pastebin.com/YwVkKza8 [01:40] I've misread that; it's not an OOM issue, but something else. [01:40] RAOF, yeah the oom bug has a slightly different error message [01:41] (and repeats it bunches) [01:41] i'm currently installing a stock maverick host to see if i can repro without the screwiness of my image [01:41] No space on device. [01:41] You know, it'd be nice if i915 wasn't almost totally silent. :) [01:42] But that dmesg doesn't show any complaints. How much of the X stack is natty's? X, libdrm, mesa, kernel are all natty? [01:43] oh, ugh. no such luck, i think. that may be my issue [01:43] i assumed getting xserver-xorg would get me everything i need, but it looks like libdrm is maverick's, for starters [01:44] Ah. Then I think you might be hitting a problem that Debian has, but we don't. [01:44] yeah esp. with -intel there are interdependencies laced throughout the stack [01:44] mesa is also natty [01:44] err, maverick [01:44] Or, rather, Debian *had* until they updated libdrm :) [01:45] If you've got natty's -intel, it'll be built against natty's libdrm, and ISTR a Debian issue where, although the ABI hadn't apparently changed, things built against the new libdrm required the new libdrm to not fail in unexpected ways. [01:46] ok. so i guess i should pull drm and mesa from natty as well? [01:46] any other important pieces? [01:46] Yup [01:46] That's basically the whole X stack; no other dependencies :) [01:46] Well, that you need to care about, at least ;) [01:49] awesome, thanks a lot. i'll re-roll my image and see what i get [01:49] broder: You're brave. [01:50] TheMuso: Fortunately I won't be deploying this to anyone but me :) [01:51] heh [01:51] That is fortunate indeed. :) [01:51] Hm. We should really update mk-sbuild to use /etc/schroot/chroot.d [01:51] And by “we”, I guess that could mean me :) [01:52] RAOF: +1. that's been bothering me in the back of my mind for months now [01:52] Also, I wonder if I could share this funky build-against-built-packages & build-on-tmpfs setup I've got going here. [01:54] I just mount a tmpfs on /var/lib/schroot/union/overlay [01:55] Though I've written code in the past to mount a new tmpfs for each overlay [01:55] build-against-built-packages sounds awesome, though [01:56] Yeah, but I need the ability to *not* build, say, mesa on a tmpfs, so I've got a special chroot target for it. Turns out you can happily share a single source chroot for multiple targets! [01:56] "Sounds like you just don't have enough swap" :-P [01:57] by default a tmpfs will only expand to 50% of available memory. Mesa uses on the order of 6GiB for a build… [01:57] My poor laptop doesn't actually have 12GiB of RAM + swap, amazingly enough :) [01:57] by default> but that can be overridden [01:58] Right. My poor laptop *also* barely has 6GiB of ram + swap :) [01:58] Haha. Fair enough :) [02:06] robert_ancell: my eyes burn now, but I fixed the conflicts [02:07] patrickmw, you've only just started :) [02:07] ok, next step is to make a new changelog entry with "dch -i" [02:07] robert_ancell: re freerdp, did you know virtualbox has an rdp server that supports tls 1.0 client certs [02:07] make sure the version is -ubuntuN" [02:07] micahg, no, I had trouble finding a server [02:08] robert_ancell: yep, virtualbox :) [02:09] micahg, I ended up using rdp_mitm in the freerdp source which is a bridge server [02:09] the vb one will be very handy if it works well [02:09] robert_ancell: Qapla! [02:11] Qapla? [02:12] robert_ancell: you don't speak klingon? [02:14] micahg, can't say I every learnt it :) [02:14] eh, that's the only word I know :) [02:17] robert_ancell: was just wishing you well in the battle with freerdp :) [02:17] micahg, ah, thanks! [02:17] patrickmw, how are you going? [02:19] robert_ancell: getting there s l o w l y [02:20] i just noticed there is a git backport naming convention, i should follow that [02:25] robert_ancell: i'm happy with the changelog now [02:26] patrickmw, ok, one thing to put in the changelog is a LP tag, e.g. (LP: #690346) [02:26] so it automatically updates the bug when the change is uploaded [02:27] then the next step is to run apt-get build-deps evolution, then debuild to build the package [02:27] its Bug #999999 [02:27] right? [02:28] Isn't it (LP: #720383) ? [02:28] i'm just looking in the changelog [02:28] That bug must be coming soon... [02:29] i don't see that notation [02:29] ah [02:29] no i do, sorry [02:31] robert_ancell: ick [02:31] robert_ancell: k [02:31] building? [02:31] just be glad there's only quilt to deal with. When I started there were at least 3 patch systems in use... [02:32] robert_ancell: E: Unable to locate package build-deps [02:33] robert_ancell: doesn't tell me what to install either [02:33] whoops, apt-get build-dep evolution [02:33] (run with sudo as normal) [02:34] robert_ancell: that's a bit generous. there are definitely still 3 patch systems in use, quilt is just slowly winning [02:34] broder, well, in the desktop package set it's pretty much done that. When you delve deep into Universe it does still get messy [02:35] broder, I'm also glad to see modern cdbs/debhelper starting to dominate too [02:36] robert_ancell: yeah, definitely [02:39] robert_ancell: build complete [02:39] patrickmw, ok, install the individual .debs (in parent directory) with sudo dpkg -i [02:39] then check no regressions, bug fixed [02:52] RAOF: took me a couple of tries to get all the requisite packages, but pulling in the new drm and mesa fixed the graphics issue. thanks again! [02:52] Hurray! [02:55] RAOF: how's our support for these new Zacate AMD fusion things? (aka. I can has new thinkpad x120e?) [02:56] jcastro: Oooh, fusion netbooks are available now, are they? [02:56] yep, just now [02:56] jcastro: I *believe* we support 3D on those. [02:56] http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087¤t-category-id=C63BB22720313B14F5906FFA72CB90D5 [02:59] Is it really $60 for Win7 professional? === asac_ is now known as asac [03:05] patrickmw, ok, going to break for lunch. The final steps are to get the packaging branch (debcheckout evolution), merge your changes in (i.e. the debian/changelog and debian/patches/), push it to your own branch (bzr push lp:~/evolution/lp-bug-720383, then do a merge request to lp:~ubuntu-desktop/evolution/ubuntu. One of the desktop team will review the merge and upload if it's good [03:07] RAOF: the whole kit together is like $500 for the one I want, so I am itching already. So basically, no pressure, you either save me $500, or entice me to spend it. [03:07] Heh. [03:07] patrickmw, oh, one more thing. Do the bzr commit with 'debcommit' and that automatically links it to the bug report [03:07] As I say, I _think_ we fully support (roughly) that GPU. [03:08] jcastro: Try it out and see! You can always give it to me if it doesnt' work :) [03:10] heh [03:29] RAOF: when you say think we support, with the open driver or with the ATI driver? [03:29] With the open driver. [03:30] It's fair to assume that anything I say which is not explicitly tagged as for the proprietary drivers is about the open drivers ;) [03:30] heh [03:31] smspillaz: cyphermox was looking for you [03:31] Amaranth: I saw that I got pinged here [03:31] couldn't find the highlighted message ;-) [03:31] cyphermox: what's up? [03:33] hey, thanks for the additional hints w.r.t updateOutputWhatever [03:34] (not looking at code, playing with my new Nexus One) [03:34] cyphermox: ah cool [03:34] I can more or less make it work that way too, except I'm having issues getting the primary screen size that way -- gdk has outdated info at the point this function runs [03:35] cyphermox: indeed. this is probably an issue that I thought might happen [03:35] I tried screen->vp () and such, but didn't quite have it yet, I'm probably not too far though [03:36] cyphermox: what I would suggest is to relayout everything on outputChangeNotify and then wait for the monitors-changed signal to see if the primary monitor changed [03:37] and do it over again if it's the case or something? [03:37] cyphermox: just change the position of the panel or something [03:37] mmkay [03:37] but you shouldn't need to do a full relayout [03:38] I'd have to look up what each piece of code does what [03:38] yeah [06:16] Who feels up to a litle light X sponsoring? [06:17] RAOF: is it universe or main? [06:17] Main. [06:17] not me :) [06:17] Or, rather, a mix of universe and main with a high main content. [06:17] :) [06:17] Ta anyway. [06:17] RAOF: I can take the universe ones [06:18] http://cooperteam.net/Packages - All of those are up for grabs; everything will depwait on the new xorg-server. [06:19] (So, if you want to do test-builds, you'll need that xorg-server, too ☺) [06:19] I can list the ones that are universy, if you like. [06:19] RAOF: actually, I'm piloting later today, so I could do them then [06:19] RAOF: err, is the xorg server built anywhere? [06:20] * micahg prefers to test build when sane [06:20] micahg: It's built locally, but not in any archive. [06:21] RAOF: would you happen to have amd64 debs I can toss in my apt-cache? [06:21] I'll throw them up there. [06:21] RAOF: thanks, I'll probably pilot in about 15 hours, so if they're not in yet, I can do them then [06:22] err, 14 hrs [06:22] :) [06:22] * micahg wants to pilot the 4 hours before feature freeze :) [06:24] Heh. [06:25] You'll hardly be busy at all! :) [06:38] Good morning [06:38] Morning pitti [07:51] good morning [07:51] hey didrocks [07:51] hey pitti, how are you? [07:51] I'm great, thanks! happy to be inside at these frosty temperatures *shudder* [07:52] heh, temperature is not that bad here, but I still feel a little chilly :) [07:53] -13 during the night [08:05] hi, didrocks, it seems that we're out of sync on package names with Debian WRT gtkhtml3.14, do you think a merge and rdepend rebuild is worthwhile? [08:05] micahg: oh really? I hadn't any time to follow seriously evolution this cycle TBH. If you want to sync package names, yeah, please do (or we can maybe wait for the next merge window as this won't be that important for natty?) :) [08:05] pitti: -13? waow [08:05] ah, it's just evolution and xiphos, so I guess I can make due with the xiphos diff [08:05] micahg: sounds good! Do not forget we are using the ~ubuntu-desktop vcs :) [08:06] didrocks: ok, does this have to be done before feature freeze or can I do this next weekend? [08:07] micahg: it's better to do before alpha3, but if you don't have time, don't worry about it :) [08:07] didrocks: yeah, I can do it this weekend [08:08] micahg: keep in mind that we have a diff on some library naming as well in the evolution stack, I don't remember exactly which was but looking at the last merge should help [08:09] didrocks: ah, yes, thanks for the note (epoch) [08:10] micahg: there is also a minor change when we don't embeed the soname in the library name, I should have a look again maybe. Not sure to have the time ;) [08:11] didrocks: what do you mean by that? [08:13] micahg: just checked, it's not on gtkhtml, so no worry :) [08:51] hey pitti, do you get a minute to discuss gir vs override [08:51] ? [08:51] sure [08:52] hello pitti [08:52] how are you? [08:52] hey seb128 [08:52] seb128: quite well, thanks! how about yourself? [08:52] so, looking with kamstrup the other day, it seems that the python override aren't installed in the good directory by default [08:52] pitti, I'm fine thanks [08:52] seb128: the last jockey crash you sent to me last night when I said good night is already fixed, FYI [08:52] (looking in my logs) [08:52] pitti, ok [08:53] didrocks: they should be in /usr/share/pyshared/gi/overrides, with the usual dh_python stuff [08:53] didrocks: I think the best place to ship them is the gir1.2-foo package, WDYT? [08:53] kamstrup: what do you use already to ship them to /usr/lib/python2.7/dist-packages/gi/overrides/Dee.py for instance? [08:53] pitti: totally agreed, I asked ken to make some change for that already few days ago [08:54] didrocks, pitti: i've copied my autofoo from pygobject/gi/overrides :-) [08:54] pitti: libgrip was creating an unused python- package and I expect people using gir won't look for it :) [08:54] didrocks: we just need to make sure to not collide file-wise with python-gobject [08:54] didrocks: i. e. not ship a gi/__init__.py [08:54] right [08:54] kamstrup: can you pastebin it? [08:55] didrocks, pitti: My Makefile.am in its entirety http://paste.ubuntu.com/571000/ [08:56] what's the problem with it? (sorry, I'm not that good at automake) -- doesn't it instlal the file? [08:56] and so pyexecdir is set to /usr/lib/python2.7/dist-packages [08:56] that sounds fine [08:56] but it seems that it's only picked upstream if it's in /usr/lib/pymodules/python2.7, isn't it? [08:57] (from my tests and after discussing with kamstrup) [08:57] no, /usr/lib/python2.7/dist-packages is correct for an upstream install [08:57] morning [08:58] (dh_python will move it to pyshared and replace /usr/lib/python2.7/dist-packages/* with symlinks, but that's just packaging) [08:58] hey rodrigo_ [08:58] pitti: it seems it wasn't picking the gir override though [08:58] what is "it"? "make install"? [08:58] it didn't install the file? [08:58] or you can't import it from python? [08:59] dh_python etc. might get confused because it doesn't look like a real module (as it's got no __init__.py) [08:59] pitti: it was installing it to /usr/lib/python2.7/dist-packages/gi/overrides/Dee.py (if we change the prefix), but python was royally ignoring it when importing the gir file [08:59] hum, maybe that's it [08:59] * popey hugs njpatel [08:59] that would be a nice try, touching __init__.py in the same directory [09:00] as Dee.py was alone there (when not packaged) [09:00] popey, heh, hey dude [09:00] pitti: ok, thanks, will try this with kamstrup and keep you in touch :) [09:01] hm, hang on [09:01] find /usr/lib/python* -name 'Gtk.py*' [09:01] what the heck? [09:01] perhaps python-support works differently here [09:01] didrocks, kamstrup: does it work if you install the file into /usr/share/pyshared/gi/overrides? [09:02] python can't find it in /usr/lib/python2.7/ if the actual gi subdir isn't there, and only in the pysupport dir [09:02] pitti: let me check [09:04] pitti: no, it doesn't seem to take it [09:05] kamstrup: confirming? [09:06] can I get Unity.py easily from somewhere? [09:06] seb128, I have an upodate for libxklavier, so do I do the same as yesterday with gsetttings-desktop-schemas, that is upload to ppa and then it will be synced from debiab? [09:06] pitti: I'll pastebin it [09:06] didrocks: is it in any package already? [09:06] seems that kamstrup abandonned us :) [09:07] pitti: no, the goal was to ship it today [09:07] hi, all! I just mumbled "scp2 must die." on #libreoffice and got only encouragement back ... frightening [09:07] pitti: so, this is the Dee.py override: http://paste.ubuntu.com/571008/ [09:07] rodrigo_, does it change the api or abi over what we have? [09:07] seb128, doesn't seem so [09:07] rodrigo_, why do you need the new version then? [09:07] pitti: with current dee gir package, you should be able to 'from gi.repository import Dee; model = Dee.SequenceModel(); model.set_schema("i", "s")' [09:07] didrocks, pitti: Doesn't work with pyshared here either [09:08] seb128, libgnomekbd needs it, so I guess there's indeed something new [09:08] pitti: if the override is there, set_schema() is known and will fail later [09:08] I'll upload to ppa and check with svu later [09:08] pitti: if it's not, set_schema() is unknown :) [09:08] rodrigo_, do the update in the ppa to start [09:08] AttributeError: 'SequenceModel' object has no attribute 'set_schema' [09:08] that's without the override, so expected [09:08] rodrigo_, I will check the diff from the ppa later on and see if we can get it in natty [09:08] right [09:08] so once that works, the override would work, right? [09:08] seb128, ok [09:09] pitti: well, it will fail later in the stack with the current package, but the function should be detected [09:09] pitti: right now, only ship it in /usr/lib/pymodules/python2.7/gi/overrides/Dee.py worked [09:09] aah [09:10] so that's where python-support is hiding them [09:10] /usr/share/pyshared really shoudln't be in the default PYTHONPATH, that'd be utterly wrong [09:11] didrocks: right, so python is looking in /usr/lib/pymodules/python2.7/ as well (for pysupport), and didn't find it there [09:11] didrocks: so, option 1 would be to use pysupport for the gir package; option 2 would be to move python-gobject to dh_python [09:11] I'd actually prefer the latter, but should be checked with the Debian maintainer first [09:12] yeah, the seconds sound more reasonable [09:12] second* [09:13] didrocks: the best test is to run examples/pythontricks.py from trunk. It exercises all the aspects of the GI+Python overrides [09:13] pitti: btw - is there are pygi way of "casting" a pointer? [09:14] kamstrup: uh, what? you don't cast stuff in Python, it's all dynamic anyway [09:14] pitti: the case in point is that I have a *signal* that emits a Dee.ModelIter - but that is using the old pygobject typesystem - I need something compatible with GI, so would like a GPointer instead [09:15] kamstrup: I'm sorry, I don't know [09:15] didrocks: do you want to look into pygobject conversion to dh_python, or want me to? [09:15] pitti: ok, it's not a blocker, just a slight hickup in the bindings :-) [09:17] pitti: not sure I have the time to do it. I'm trying to concentrate as much as possible on hacking upstream and still have a lot planned on that, but if you don't have the time either, I'll do it [09:17] didrocks: ok, let me have a look then [09:18] pitti: thanks a lot :) [09:43] good morning everyone [09:43] morning chrisccoulson [09:43] hi smspillaz [09:44] hey chrisccoulson [09:44] hi pitti, how are you? [09:44] w00t, mozilla are starting their beta 12 builds now [09:44] * chrisccoulson has some uploading to do :) [09:45] hey chrisccoulson, how are you? [09:45] hi seb128, i'm good thanks [09:45] i think i've figured out those memory errors you see btw [09:45] oh, nice, what is it? [09:45] did you drop your comments in the bug? [09:45] or talked to ted? [09:46] not yet [09:47] ok, now I blame the mozilla guys to divert you from fixing that with next builds ;-) [09:47] lol [09:47] i'll sort this crasher out first ;) [09:47] do you think you can get a patch today or tomorrow? [09:47] excellent [09:49] pitti: Good morning! [09:49] pitti: Twice I've seen you say "a lot" [of problems/confusion] about LC_MESSAGES and ssh. How bad is it? Second thoughts about the whole thing? [09:49] pitti: I've seen one private mail and possibly one bug report. The switch from .utf8 to .UTF-8 (bug 666565) might improve it. [09:49] Launchpad bug 666565 in language-selector ""utf8" charmap in locale name is wrong" [Undecided,Fix released] https://launchpad.net/bugs/666565 [09:52] GunnarHj: hi! [09:52] GunnarHj: the main problem is that ssh exports LC_MESSAGES to the remote side [09:52] and most ~.profile etc. remember to set LANG to a locale appropriate for that server, but not LC_MESSAGES [09:53] and thus you end up with a broken locale in many cases [09:53] this is not really a "bug" in the sense that the gdm change is wrong, but it's an unintended side effect [09:53] well, let's rather say "unexpected" [09:56] Anyone up for some X sponsoring? 1.10RC2, multitouch, and a bunch of crasher fixes. [09:58] pitti: One thought is to turn it around and use LANG for message translation, and set a bunch of LC_* variables for the other format stuff. Haven't really considered it, don't know if it would be better. [09:58] GunnarHj: that wouldn't help a lot either, I think [09:59] GunnarHj: I think it's fine the way it is now, but it requires some config file adaptions on remote sites for users [10:01] pitti: Which leads to the question: Is there a way to make people aware of that need? What kind of info follows an Ubuntu release? [10:01] didrocks: hm, moving pygobject to dh_python2 breaks all other packages which ship stuff in /usr/lib/pyshared/python2.7/gtk-2.0/ (python-vte, python-gconf, python-gnome2, python-gnomecanvas, python-notify, python-gtkspell, python-glade2, python-gtk2, python-wnck, python-gnomekeyring) [10:02] didrocks: I guess all of these are just two or three source packages, but they would all require an update in lockstep [10:02] didrocks: do you think you could use dh_python and additionally ship a manual symlink in /usr/lib/pyshared/ to make it work with both? [10:02] kamstrup: ^ FYI [10:03] pitti: ah, of course :/ yeah, your solution sounds good to me [10:03] well, "hack" [10:03] right "hack" ;) [10:03] I'll send my patch to Debian with appropriate remarks [10:04] yeah, and maybe ask for policy for the gir override files as well? So that everyone ship in the gir- package [10:05] didrocks: that should be discussed in #introspection or #Python on irc.gnome, I think [10:05] * pitti asks [10:07] RAOF, can do if nobody did it yet [10:11] seb128: Thanks; no-one seems to be feeling particularly sponsorific. It's all of http://cooperteam.net/Packages ; build order is x11proto-input, xserver, everything else. Everything has appropriately versioned build-depends (this time!) so should happily sit in dep-wait. [10:14] RAOF, ok [10:16] It can wait for Bryce in the morning if that looks like a lot. [10:17] didrocks: ok, mail/bug sent [10:17] RAOF: got a highlight problem? ;) [10:19] Well, I generally broadcast rather than ping :) [10:20] heh, well i replied on #ubuntu-x, so if seb128 has hands full I can sponsor them [10:20] is notify-osd broken for anyone else? the bottom and right-hand edges of my notifications are clipped for some reason [10:20] tjaalton: !!! Aaah. I did not notice that! [10:20] tjaalton, I'm on the phone so feel free to sponsor [10:20] * RAOF *does* have a highlight problem! [10:20] seb128: ok, will do [10:21] RAOF: :) [10:22] Is the GNOME stack in the PPA usable now? [10:23] oh, bug 670785 [10:23] Launchpad bug 670785 in notify-osd "Noitfy-osd uncompatible with pixman 0.20.0?" [Medium,Confirmed] https://launchpad.net/bugs/670785 === Nafallo_ is now known as Nafallo [10:31] cdbs: have you made any progress on bug 630383? I'm having it and it is really rather annoying [10:31] Launchpad bug 630383 in libdbusmenu "Gnome-terminal paste keyboard shortcut does not work - menu not shown" [Undecided,New] https://launchpad.net/bugs/630383 [10:32] Laney: :o I forgot it, will look at it now. If not able to fix, I'll un-assign [10:32] ok [10:34] fwiw I don't run unity or the global menu [10:52] pitti, so I saw your conversation with GunnarHj earlier on, and I've noticed that I've got several locale-related error messages on an ssh connection. And it seems it has to do with what you were saying: LC_MESSAGES gets exported to the server, which does not seem to recognize it. What's the best way to solve this? [10:53] i.e. not as in fixing the bug, but rather, is there a workaround? [10:54] dpm: you need to update your remote ~/.profile or ~/.bashrc to also set LC_MESSAGES, not just LANG [10:54]