[00:11] where's warner, find warner! [00:13] ? === attente is now known as attente_zzz [02:05] mlankhorst: ? :) === jasoncwarner_ is now known as jasoncwarner [02:06] from the wheres jason emails :) [02:08] mlankhorst: ah....can't believe we let someone in from a non-approved country...I mean, what's up with that?! ;) [02:09] * mlankhorst whistles [02:09] .eu is a country right? [02:31] Man, that compiz SRU included more faffing around than was really necessary. [03:09] jasoncwarner, who are you and why are you trying to impersonate jasoncwarner_? [03:11] * desrt notes that a really large portion of the desktop team is from commonwealth and/or francophonie nations [03:11] * desrt notes that the plurality country of the desktop team is a commonwealth member of the francophonie === m_conley_away is now known as m_conley [03:20] m_conley: hey [03:20] m_conley: see this? http://news.cnet.com/8301-1023_3-57554885-93/gmail-meet-google-drive-and-behold-10gb-file-transfers/ [03:23] desrt: good lord [03:23] desrt: 10gb [03:32] m_conley: the idea seems.... familiar, somehow [03:32] *-* [03:34] desrt: if you're referring to Filelink, 10GB is way outta range. :) I think YouSendIt, Box and Dropbox cap at something like 500MB per file. [03:35] still, it might be nice if somebody built a Filelink provider for Google Drive [03:35] m_conley: not really referring to the file size so much as the idea... [03:35] desrt: righto === m_conley is now known as m_conley_away [05:54] Good morning [05:55] jasoncwarner: I'm not actively working on unity bits right now; nobody asked me for some specifics what to help with so far [05:56] guess I'll talk to pgraner and mmrazik [06:09] good morning [06:12] good night :p [06:14] hey desrt, enjoy! ;) [08:04] pitti: good morning! re bug #1078297> is this in -proposed waiting for inclusion since "2012-11-13"? i.e. my upload was rejected because its already there? [08:04] Launchpad bug 1078297 in pygobject (Ubuntu Quantal) "Crashes with GLib.child_watch_add" [Undecided,In progress] https://launchpad.net/bugs/1078297 [08:05] pitti: please note that in order to fix this in software-center there needs to be a software-center fix as well, so it may be better to unduplicate the s-c bug or to add a new software-center task, either way is fine with me [08:05] mvo: good morniung [08:06] mvo: sorry, I should have thought about this upload yesterday, but I forgot about it [08:06] mvo: yes, it has indeed been in the queue for > 2 weeks already :( [08:06] mvo: ah ok; let's unduplicate then, and close the pygobject task with a reference to the other bug [08:07] pitti: thanks, will do [08:07] doing already [08:07] pitti: cool, even better :) [08:07] pitti: its a bit frustrating that LP gives on visibility into uploads that wait for review ./ [08:07] mvo: it does: https://launchpad.net/ubuntu/quantal/+queue?queue_state=1 [08:07] good morning mvo :) [08:08] mvo: ok, I updated both bugs now [08:08] mvo: I sent the explanation to bug 1083694 this morning, BTW [08:08] Launchpad bug 1083694 in software-center (Ubuntu Quantal) "crash/hang when submiting review updates" [Undecided,In progress] https://launchpad.net/bugs/1083694 [08:09] pitti: aha, need to keep that in my bookmarks [08:09] didrocks: good morning! [08:11] pitti: if you could look at/approve https://code.launchpad.net/~mvo/software-center/5.4-fix-threading/+merge/136475 that would be perfect, then I do the software-center SRU now [08:13] mvo: commented (LGTM) [08:13] ta [08:13] * mvo prepeares upload [08:50] hey desktopers [08:50] salut seb128 ! [08:51] Laney: hey, do you know which branch we should push for the SRU when using canonical branches? lp:ubuntu/quantal-proposed/compiz doesn't work and I never find the right syntax [08:52] hey didrocks, en forme ? [08:52] seb128: ça va bien! commencé avec une longue discussion ;) [08:52] et toi? [08:52] bonjour seb128 [08:52] ca va bien [08:53] didrocks, that's the correct vcs but I think it doesn't exist until the first upload to that pocket [08:53] pitti, lut! [08:53] seb128: yeah, but it's been accepted [08:53] this morning [08:53] hence my question ;) [08:54] didrocks, https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/compiz/quantal [08:54] but yeah, not for proposed...launchpad bug? [08:54] maybe… [08:55] let me try s/quantal/quantal-proposed [08:55] with the long form [08:55] $ bzr push lp:~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed [08:55] bzr: ERROR: Permission denied: "~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed/": : Didier Roche is not a member of Ubuntu branches [08:55] no luck [09:00] NB you can't create new branches that way [09:00] if it already exists, you can use it [09:00] (exists from a previous SRU, as the package importer created it) [09:01] can a shebang be more than 80 characters? i'm guessing not by my thunderbird build error: [09:01] bash: /home/chr1s/src/thunderbird/build-area/thunderbird-trunk-20.0~a1~hg20121127r11622.114209/obj-x86_64-linux-gnu/mozilla/_tests/mozmill-virtualenv/bin/easy_install: /home/chr1s/src/thunderbird/build-area/thunderbird-trunk-20.0~a1~hg20121127r11: bad interpreter: Permission denied [09:02] chrisccoulson: it's more likely that the interpreter is missing the +x perm [09:03] pitti - the interpreter is executable. the interpreter is truncated to 80 characters in the error message though [09:03] i wonder why i've not hit this in firefox yet :/ [09:03] hm, I never heard about such a limitation [09:03] me neither, that's why i'm confused ;) [09:04] it seems too much of a coincidence that the shell has truncated it to 80 characters though [09:04] didrocks: yeah, just use a debdiff for SRUs, at least for the first one :( [09:04] morning! [09:04] Laney: it's accepted right now [09:04] Laney: so, I want to push my branch :) [09:04] did the importer not create it yet? [09:05] chrisccoulson: confirmed [09:05] $ cp /bin/bash /tmp/`seq -s '' 1 100` [09:05] then I created a /tmp/test.sh with that, and it fails with the same error [09:05] thanks [09:06] chrisccoulson: hm, running through /usr/bin/env doesn't help either [09:06] firefox is using python-virtualenv quite extensively throughout the build. that must be fairly close to failing as well [09:06] Laney: doesn't seem so (compiz on quantal) [09:07] calling /tmp/12345678910 /tmp/test.sh works, though [09:07] chrisccoulson: so you might need to call the interpreter explicitly [09:07] Laney: and it's the second compiz SRU [09:07] weird black magic [09:07] oh, http://package-import.ubuntu.com/status/ [09:07] pitti, thanks. i'll modify the build system to do that [09:08] maybe a member of ~ubuntu-branches (someone on the TB ...) could do it manually if that wouldn't brea kstuff [09:08] Laney: ok, I'll ask for it [09:08] thanks Laney ;) [09:09] if only I knew someone of the TB [09:09] oh a pitti! :) [09:09] * pitti runs === pitti is now known as universal_tb_pri [09:09] pitti: too late :-) would you mind pushing lp:~didrocks/compiz/quantal to some quantal-proposed branch? :) [09:09] oh, that didn't work === universal_tb_pri is now known as pitti [09:09] ahah :) [09:09] /nick universal_tb_priv_command_executor [09:10] didrocks: "some"? [09:10] didrocks: the UDD branch, or some ~ubuntu-core-dev etc. one? [09:10] pitti: I guess lp:ubuntu/quantal-proposed/compiz is the canonical url? [09:10] ah, so the UDD one [09:10] yes please :) [09:11] or is it for ~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed/ for the full url? [09:11] same thing [09:11] * didrocks like the UDD short one, the only one I can remember even if the second is indeed logical [09:12] bzr: ERROR: Der Server meldete einen unerwarteten Fehler: ('error', 'xmlrpclib.Fault', ', )">') [09:12] Laney: I think I just discovered yetanotherurl :) [09:12] heh [09:12] pitti: I think you need to use the full URL first [09:12] that's the "why isn't UDD working?!?!?!" url [09:12] pitti: at least, that's where I got the "permission denied" [09:12] bzr push bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/quantal-proposed/compiz [09:12] same error [09:12] Laney: heh ;) [09:12] ah? [09:12] even with ~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed/ ? [09:13] $ bzr push lp:~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed [09:13] that seems to get further [09:13] Packaging branch version: None [09:13] Packaging branch status: OUT-OF-DATE [09:13] Created new stacked branch referring to /+branch-id/673165. [09:13] and done [09:13] thanks pitti ;) [09:13] bzr branch lp:ubuntu/quantal-proposed/compiz -> still failing, though [09:13] * didrocks is trying as well [09:13] yeah, failing [09:14] didrocks: any reason to not just upload it and let the importer sort it out? [09:14] you can then push --overwrite, to "fix" the history [09:14] pitti: well, it's been 2 uploads (and 2 months) that the first SRU is released [09:14] but I never found UDD to work well for SRUs [09:14] pitti: and it was never imported [09:14] pitti: we use it for the daily build pre-raring (pre packaging-inlining) [09:15] the compiz importer is broken per that URL I gave a minute ago [09:16] hence we used the pitti-universal_tb_priv_command_executor trick :) [09:17] yeah, just saying that's why 'just upload'ing didn't work :) [09:19] The concept of how the UDD importer should work in concert with packagers who actually *use* UDD too seems sadly fuzzy :-/ [09:20] Which makes fixing it rather hard [09:22] it's hard to advocate that people try to use it when there's still roadblocks like these [09:22] like it doesn't really matter if the importer is broken for a package which is actively maintained in UDD until you can't push your SRU branches because there's no way for mortals to create them [09:24] I agree [09:24] that's one (but not the only one) of the reason that we are going with inline packaging for the unity stack [09:24] (knowing that make dist doesn't distribute the packaging) [09:25] pitti, oh, it's actually fixed in newer versions of python-virtualenv [09:25] pitti, https://github.com/pypa/virtualenv/blob/develop/virtualenv.py#L637 [09:26] The SRU branch thing is, I guess, something solely needing fixing on the LP side [09:26] chrisccoulson, backport the patch ;-) [09:26] Other problems are the importer's completely unhelpful rendering of v3 quilt packaging branches, and it having fights with ever-so-slightly-different revisions that humans push [09:31] right, trying the build again. hopefully i get a nice shiny testsuite to run at the end of it :) [09:33] hiya [09:33] can anyone reply to https://twitter.com/lmukadam/statuses/273548780324925440 please? [09:36] dholbach, salut [09:37] dholbach, no plan to change anything yet, geary is too new to even consider it [09:38] ok, will reply [09:38] new and shiny? but that's the only criteria isn't it? ;) [09:40] in raring when I run xvfb-run for my software-center tests I see hangs - anyone lese having trouble with that in raring? === Sweetsha1k is now known as Sweetshark [09:43] mvo: not here, seems to work fine; I use xvfb-run in pygobject and apport, and the autopkgtest never failed for those [09:44] pitti: thanks, that is good to know [09:44] mvo: I do have to wait for a previosu instance to finish before I run the next one, though (for tests which start xvfb multiple times) [10:02] jibel: FYI, oif bootstrapped as well (and added more to misc for autopilot and so on) [10:02] 21 projects are live now [10:03] 4 indicators are ready, but waiting on tests to be fixed [10:03] 16 for unity are ready, but waiting on autopilot === vrruiz_ is now known as rvr_ [10:18] pitti: hm,hm, it appears that the new python-gi affects signal handling in some way, this http://paste.ubuntu.com/1394083/ used to work (I use it in the software-center testsuite) but does no longer stop aptd, the signal does not reach it. but my naive http://paste.ubuntu.com/1394086/ reproduce script is doing fine [10:20] $ aptd --dummy --session-bus [10:20] that runs here, how does it fail for you? [10:21] pitti: it runs but it won't stop on sending sigterm [10:21] pitti: that used to work [10:21] killall -TERM aptd [10:21] indeed [10:21] mvo: can you please file a bug about it? that seems to be a rather serious regression [10:22] mvo: on bugzilla preferrably, but LP is okay, too [10:22] pitti: sure, hold on a sec, its not entirely trivial to reproduce, I'm working on a testcase right now [10:22] mvo: but report with apt seems fine; I'll see to writing a test case then [10:27] pitti: https://bugzilla.gnome.org/show_bug.cgi?id=689208 [10:27] Gnome bug 689208 in general "signal handling issues with 3.7 issues" [Normal,Unconfirmed] [10:27] pitti: do you have a idea already or is it worth for me to explore a bit more on the minimla testcase front? [10:28] mvo: I have an idea [10:28] mvo: danke fuer den report [10:30] mvo: presumably from this tiny commit: http://git.gnome.org/browse/pygobject/commit/?id=191cf45a [10:31] mvo: I'l have a look ASAP [10:31] note, regardless how many tests you write, there is always the n+1st bug [10:36] pitti: heh, so true - it bugs me a bit that I can't write a easy testcase [10:37] i wonder why kenvandine uploaded the original patch from bug 1076350? [10:37] Launchpad bug 1076350 in WebApps: unity-firefox-extension "Crash when navigating to another page immediately after initializing unity integration" [Undecided,Fix committed] https://launchpad.net/bugs/1076350 [10:37] mvo: I hope that tests/test_mainloop.py test_sigint() written with s/INT/TERM/ will reproduce it [10:43] hm, killing a simple MainLoop with SIGTERM works fine [10:46] mvo: http://paste.ubuntu.com/1394144/ succeeds here; so I guess aptdaemon is doing something slightly more complicated [10:48] pitti: yeah, like I wrote before, a trivial testcase worked for me too, aptdaemon is doing more stuff indeed, dbus for a start, not sure if that affects it. and is using the dbus glib mainloop [10:49] import dbus.mainloop.glib [10:49] dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) [10:49] when I add this to the test, it still works [10:49] mvo: ok, I'll keep digging [10:49] chrisccoulson, he likely didn't follow the issue closely enough and picked the first one he crossed [10:49] yeah, same here :/ [10:50] [pid 9375] --- SIGTERM (Terminated) @ 0 (0) --- [10:50] [pid 9375] rt_sigreturn(0xf) = -1 EINTR (Interrupted system call) [10:50] mvo: ^ that's what strace shows me in apt; EINTR sounds fishy [10:51] pitti: indeed, same here [10:53] oh, old pygobject apparently installed a signal handler for all signals, not just SIGINT [10:54] so this seems to be a GLib thing which previously has been shadowed by a pygobject hack [10:54] pitti: so its all desrt fault? [10:55] so in a way this brings current pygobject closer to the glib behaviour, but is of course a behavioural change [10:56] hm, but even if I do install a SIGTERM handler, it's not being called [10:57] hm, aptdaemon does a lot of signal handling by itself, RTFS [10:57] ./aptdaemon/core.py: signal.signal(signal.SIGTERM, self._sigquit) [11:00] mvo: ^ when I comment this out, it works [11:00] (it doesn't call its .Quit(), of course) [11:02] pitti: right [11:03] why don't you use glib's signal sources? [11:03] they play nice with mainloop [11:04] mhr3: no reason really, let me see if that fixes it [11:05] mhr3: well, except "introspectable="0"" in g_unix_signal_add [11:05] unix_signal_add_full() [11:05] cool [11:06] this is missing an annotation in glib to expose itself as unix_signal_add [11:08] hrm, hrm, hrm, no cookie for me with that as well, this works in my minimal sigterm.py but no trace of delivery in aptdaemon [11:09] oh, no [11:10] if used correct it seems to be fine *cough* [11:11] mvo: FYI: http://git.gnome.org/browse/glib/commit/?id=fca30c3e165d [11:11] pitti, mhr3: thanks, I prepare a branch for that, regardless of the bug this is cleaner to use [11:11] pitti: \o/ [11:11] mvo: that will break a call to _full(), though [11:12] but it's more consistent that way with the other API [11:12] pitti: I'm not sure I understand, can I still ue _full() ? [11:12] no, that'll be unix_signal_add() then [11:13] pitti: ok, so I will prepare the branch and note that it needs a later pygobject [11:13] that's a bit of a problem with "Rename to:" [11:13] mvo: not pygobject, but gobject-introspection (which ships the GLib .gir) [11:13] c'est difficile :( [11:13] pitti: could there be a compat interface? i.e. deprecation warning but still providing the other name? [11:14] yes, I can add an override [11:14] pitti: other people might use _full() already, no? [11:16] pitti: oh, joy, SIGQUIT is used right now but not supported by the g_unix_signal_source_new but I guess its esoteric enough that it can be ignored? [11:17] right, SIGQUIT doesn't seem to work either [11:17] mvo: that's Ctrl+\ [11:17] not that big of a deal, I guess [11:18] pitti: yeah [11:18] (thats what I meant with esoteric :) === gatox_ultra is now known as gatox [11:21] mvo: http://git.gnome.org/browse/pygobject/commit/?id=e45c690bc83b6d513887649de88965a9752e316d [11:23] pitti: https://code.launchpad.net/~mvo/aptdaemon/use-glib-unix-signal-handling/+merge/136626 <- if that looks ok I will merge/upload [11:23] pitti: nice! [11:24] LGTM, MP updated [11:24] as for the bugzilla report, I'm still not quite sure what happens here [11:24] so glib does something funky with signals, and aptdaemon re-routes it [11:25] and pygobject's former re-routing (which also used g_unix_signal) somehow made it work [11:25] * pitti installs pygi 3.4 to see which one was actually called [11:26] mvo: hm, I installed 3.4.2, and that didn't work either [11:26] oh, I'm sorry; I had a hacked source [11:26] it does [11:26] :) [11:27] mvo: so because the old pygobject installed a signal watch pipe, aptdaemon's signal handler got enabled [11:27] fun [11:30] * mvo prepares upload [11:36] mvo: hm, http://paste.ubuntu.com/1394226/ with 3.4 exits with a KeyboardInterrupt, and the handler doesn't get called [11:36] * mvo needs to head of for lunch [11:56] seb128: no irc log in the weekly summary? [12:15] hey guys is there a way to enable fglrx without Unity disappearing from the desktop in Quantal yet? === attente_zzz is now known as attente [13:15] pitti: if you have a moment https://code.launchpad.net/~mvo/aptdaemon/multiline-comments-fix/+merge/136656 is needed before I can do a new aptdaemon upload as otherwise my tests are breaking, quick eyeball would be great [13:16] mvo: fun, so */ was handled, but not /* ? [13:17] pitti: yeah, I was a bit puzzled by this too [13:17] +1ed [13:18] \o/ [13:21] * Laney uploads a test gstreamer 1.0 package [13:22] brasero [13:23] yawn [13:23] seb128: I am uploading a 3.5.7-0ubunutu2 adding bug 595910 to chinstrap. I havent tested that build locally yet, but am uploading to ppa right now (although it likely will fail because of size). [13:23] Launchpad bug 595910 in Launchpad itself "Forbidden error on +participation" [High,Fix released] https://launchpad.net/bugs/595910 [13:23] Laney, \o/ [13:23] desrt, hey [13:23] hi [13:24] it's the smallest impact one I could find (no -good dep) [13:24] Sweetshark, how much change does that update contain? wouldn't it be a good idea to test it? ;-) [13:24] so should let us promote the main libraries [13:24] Laney, cool [13:27] seb128: vs. the 3.5.7-0ubuntu1 upload? one patch that, a/ is on upstream master b/ has been reviewed on upstream 3.6 for backporting (and thus will be in quantal with the next 3.6.4 upload) c/ has even been uploaded for raring (although that was a waste of ressources) [13:27] Sweetshark, ok [13:31] * desrt kicks off morning jhbuildage [13:33] Sweetshark, uploaded [13:33] hey desrt [13:34] long time no see ;) [13:34] didrocks: :) [13:34] done [13:34] * Laney is scared now [13:35] seb128: thx [13:35] Sweetshark, yw! [13:36] if someone wants to promote gst-plugins-base1.0 to main it should be able to build right away === smspilla1 is now known as smspillaz [13:42] i've a weird lightdm issue where lightdm appears to be working fine, but I see the console output with the mouse cursor (and hear bongos) [13:42] this after reboot [13:42] lightdm restart makes it normal again [13:43] Sweetshark, Rejected: [13:43] libreoffice_3.5.7-0ubuntu2.dsc: Version older than that in the archive. 1:3.5.7-0ubuntu2 <= 1:3.6.2~rc2-0ubuntu3 [13:43] Sweetshark, you probably want to target precise-proposed rather than quantal? [13:44] tjaalton, not sure, seems like a vt race between xorg/plymouth/lightdm? [13:44] plymouth isn't used in this case, ruled it out [13:44] also, when I vt change the mouse is still there.. [13:45] oh well, I'll bug the intel guys then [13:46] * Laney smiles sweetly at seb128 and didrocks and runs off to lunch [13:46] Laney, I will have a look in a bit if didrocks, with his MIR hat, doesn't beat me [13:46] theorically it's a MIR team job ;-) [13:47] * didrocks feels no social pressure [13:47] tjaalton, thanks [13:47] didrocks, not at all [13:47] ;-) [13:47] I don't think it needs it as 0.10 is already in main [13:47] at least infinity promoted the main gstreamer1.0 package on that basis [13:47] Laney, susssh, don't ruin my plan :p [13:47] :P [13:47] I'll just promote I guess after a quick look [13:48] lunch → to the running shoe shop [13:48] * Laney fears for his heart and lungs [13:48] Laney: enjoy! [13:54] seb128: dah, indeed. brainfart. [13:55] seb128: fixing [13:55] Sweetshark, thanks [13:55] chrisccoulson: hm, where can I see firefox' cookie blacklist? [13:56] chrisccoulson: I removed some, and now firefox apparently automatically blacklisted the site I was removing cookies for [13:56] and I can't figure out how to get them back [13:56] pitti, permissions.sqlite [13:56] didrocks, yay for seeing the first autolanding for webapps :) [13:57] oh is that network.cookie.blockFutureCookies ? [13:57] (in about:config) [13:57] chrisccoulson: ^ that's "true" for me now [13:57] * pitti resets it [13:57] kenvandine: yeah \o/ [13:57] kenvandine: now your turn to bootstrap all the stack we are confident with! :) [13:58] i manually did the last release of unity-firefox-extension just to get fixes out there [13:58] chrisccoulson: ah, so there's no UI for this? [13:58] pitti, i'm not even sure that setting is used anywhere [13:58] no, still doesn't work [13:59] kenvandine, hey, speaking of which, chrisccoulson suggested you took the wrong version of the patch you applied to it [13:59] oh? [13:59] i took what was merged into trunk [13:59] chrisccoulson, i wonder why kenvandine uploaded the original patch from bug 1076350? [13:59] Launchpad bug 1076350 in WebApps: unity-firefox-extension "Crash when navigating to another page immediately after initializing unity integration" [Undecided,Fix committed] https://launchpad.net/bugs/1076350 [14:00] kenvandine: so maybe we can have an automated one for the fix? :) [14:00] * didrocks sees that as an opportunity [14:00] chrisccoulson, i took rev 348 [14:00] seb128: just for completeness: should the last-version in genchanges be the last successful -proposed upload, or the last successful precise upload? [14:00] so i guess they merged the wrong version of the fix [14:01] Sweetshark, the current version in -updates [14:01] seb128: k [14:01] seb128: then it was right for a change ;) [14:01] Sweetshark, e.g you want to list everything > 1:3.5.4-0ubuntu1.1 [14:02] oh... that was the CVE [14:02] seb128: yep [14:02] that was the version that mdeslaur uploaded [14:02] i didn't modify the patch [14:07] huh? I took r350 and r351... https://launchpadlibrarian.net/123717655/unity-firefox-extension_2.4.1-0ubuntu1_2.4.1-0ubuntu1.1.diff.gz [14:07] hey mdeslaur [14:07] kenvandine: hi! [14:07] kenvandine: I'm a bit confused :) [14:07] it hasn't been merged into trunk yet [14:07] https://code.launchpad.net/~zaspire/unity-firefox-extension/listen-tab-close/+merge/135266 [14:07] i am too :) [14:07] chrisccoulson: ok, "select * from moz_hosts where type = 'cookie';" did the trick [14:08] chrisccoulson: I'm sure my mother could figure this out :) [14:08] kenvandine: ah, yes, chrisccoulson told me that was the wrong one [14:08] kenvandine: the right fix is r350..351 from here: https://code.launchpad.net/~chrisccoulson/unity-firefox-extension/lp1076350 [14:09] ah [14:09] of course, the right, right fix would be to rewrite it to stop attaching document specific objects to the outer window :) [14:09] so the other branch shouldn't get merged [14:10] someone should kill that MP :) [14:10] chrisccoulson, is it worth another upload to change that? [14:10] kenvandine, not really. i suspect that would be a much bigger change tbh [14:10] ok [14:11] well i need to relocate to the car dealership, getting work done :) [14:11] and if you asked me to do that, i'd probably just start from scratch ;) [14:11] hehe :) [14:11] i'll be back in ~20-30m [14:12] pitti, there are some issues atm (see https://bugzilla.mozilla.org/show_bug.cgi?id=814554) [14:12] Mozilla bug 814554 in General "Firefox 17 silently stops processing permissions.sqlite when rejecting rules valid under Firefox 16" [Normal,Assigned] [14:12] yours seems like the opposite problem though ;) [14:13] seb128: I dont need to version bump as this was rejected anyway, right? [14:13] Sweetshark, correct, you never need to bump version for things that don't leave the queue [14:13] Sweetshark, queue doesn't count, you can have several times the same version in it [14:16] seb128: I guessed so, but still a bit uncertain as I never do the sponsoring ... [14:31] seb128: fixed on chinstrap, currently building (although not on precise, but on quantal -- by precise pbuilder is already gone as 3.5.7 was the last upstream micro for 3.5) [14:32] Sweetshark, ok [14:52] Laney: the packaging looked sane, I promoted the whole stack as the only one which was not in main was the gnomevfs one which obviously doesn't exist anymore [15:03] didrocks: merci! [15:04] de rien :) === gatox is now known as gatox_lunch === vrruiz_ is now known as rvr_ === m_conley_away is now known as m_conley === gatox_lunch is now known as gatox [16:16] pitti: sorry for naging again, just to double check "GLib.io_add_watch()" is really io_add_watch_full() i.e. I need to look at the signature of that C functions for the paramter order? or is there a better way to find out how its correctly called? working on lp:~mvo/software-center/fix-pygobject-deprecation-warnings atm [16:17] mvo: right, that one already has a Rename: [16:17] c:identifier="g_io_add_watch_full" [16:18] shadows="io_add_watch"> [16:18] in /usr/share/gir-1.0/GLib-2.0.gir [16:19] pitti: and I use GLib.PRIORITY_HIGH or will that become GLib.Priority.HIGH at some point (like most of the other consts)? [16:20] Sweetshark, you got the .changes list of versions wrong (not a stopper), just pointing it ... I said > 1:3.5.4-0ubuntu1 not >= ... eg you should include all the changes since what is in -updates, 1:3.5.4-0ubuntu1 being in update it shouldn't be included [16:20] mvo: no, those are global constants, not enums (historical reasons?) [16:20] mvo: i. e. GLib.PRIORITY_HIGH is fine [16:20] pitti: aha, ok [16:41] * Sweetshark realizes he still reads "historical reasons" as "hysterical reasons" from his OpenOffice.org times .... [17:20] mpt: I have another question regarding Contributor Console. === Sweetshark is now known as Sweetsharl === Sweetsharl is now known as Sweetshark [17:33] hello, i sent up an MP yesterday, but not sure if the right folks got notified... https://code.launchpad.net/~achiang/appmenu-gtk/memleaks-787736-780602/+merge/136550 [17:33] kenvandine: ^^ ?? [17:34] * kenvandine looks [17:35] charles, larsu: i assume one of you are looking after appmenu-gtk right? [17:35] oh, that's a backport [17:35] right [17:35] * charles looks [17:35] the fix is already in trunk [17:35] so you want to SRU that to precise? [17:35] but it never got into precise [17:36] correct [17:36]