[00:11] <mlankhorst> where's warner, find warner!
[00:13] <attente> ?
[02:05] <jasoncwarner_> mlankhorst: ? :)
[02:06] <mlankhorst> from the wheres jason emails :)
[02:08] <jasoncwarner> 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] <mlankhorst> .eu is a country right?
[02:31] <RAOF> Man, that compiz SRU included more faffing around than was really necessary.
[03:09] <robru|packing> 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
[03:20] <desrt> m_conley: hey
[03:20] <desrt> m_conley: see this?   http://news.cnet.com/8301-1023_3-57554885-93/gmail-meet-google-drive-and-behold-10gb-file-transfers/
[03:23] <m_conley> desrt: good lord
[03:23] <m_conley> desrt: 10gb
[03:32] <desrt> m_conley: the idea seems.... familiar, somehow
[03:32] <Chucrute301> *-*
[03:34] <m_conley> 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] <m_conley> still, it might be nice if somebody built a Filelink provider for Google Drive
[03:35] <desrt> m_conley: not really referring to the file size so much as the idea...
[03:35] <m_conley> desrt: righto
[05:54] <pitti> Good morning
[05:55] <pitti> 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] <pitti> guess I'll talk to pgraner and mmrazik
[06:09] <didrocks> good morning
[06:12] <desrt> good night :p
[06:14] <didrocks> hey desrt, enjoy! ;)
[08:04] <mvo> 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] <ubot2> Launchpad bug 1078297 in pygobject (Ubuntu Quantal) "Crashes with GLib.child_watch_add" [Undecided,In progress] https://launchpad.net/bugs/1078297
[08:05] <mvo> 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] <pitti> mvo: good morniung
[08:06] <pitti> mvo: sorry, I should have thought about this upload yesterday, but I forgot about it
[08:06] <pitti> mvo: yes, it has indeed been in the queue for > 2 weeks already :(
[08:06] <pitti> mvo: ah ok; let's unduplicate then, and close the pygobject task with a reference to the other bug
[08:07] <mvo> pitti: thanks, will do
[08:07] <pitti> doing already
[08:07] <mvo> pitti: cool, even better :)
[08:07] <mvo> pitti: its a bit frustrating that LP gives on visibility into uploads that wait for review ./
[08:07] <pitti> mvo: it does: https://launchpad.net/ubuntu/quantal/+queue?queue_state=1
[08:07] <didrocks> good morning mvo :)
[08:08] <pitti> mvo: ok, I updated both bugs now
[08:08] <pitti> mvo: I sent the explanation to bug 1083694 this morning, BTW
[08:08] <ubot2> Launchpad bug 1083694 in software-center (Ubuntu Quantal) "crash/hang when submiting review updates" [Undecided,In progress] https://launchpad.net/bugs/1083694
[08:09] <mvo> pitti: aha, need to keep that in my bookmarks
[08:09] <mvo> didrocks: good morning!
[08:11] <mvo> 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] <pitti> mvo: commented (LGTM)
[08:13] <mvo> ta
[08:13]  * mvo prepeares upload
[08:50] <seb128> hey desktopers
[08:50] <didrocks> salut seb128 !
[08:51] <didrocks> 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] <seb128> hey didrocks, en forme ?
[08:52] <didrocks> seb128: ça va bien! commencé avec une longue discussion ;)
[08:52] <didrocks> et toi?
[08:52] <pitti> bonjour seb128
[08:52] <seb128> ca va bien
[08:53] <seb128> didrocks, that's the correct vcs but I think it doesn't exist until the first upload to that pocket
[08:53] <seb128> pitti, lut!
[08:53] <didrocks> seb128: yeah, but it's been accepted
[08:53] <didrocks> this morning
[08:53] <didrocks> hence my question ;)
[08:54] <seb128> didrocks, https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/compiz/quantal
[08:54] <seb128> but yeah, not for proposed...launchpad bug?
[08:54] <didrocks> maybe…
[08:55] <didrocks> let me try s/quantal/quantal-proposed
[08:55] <didrocks> with the long form
[08:55] <didrocks> $ bzr push lp:~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed
[08:55] <didrocks> bzr: ERROR: Permission denied: "~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed/": : Didier Roche is not a member of Ubuntu branches
[08:55] <didrocks> no luck
[09:00] <pitti> NB you can't create new branches that way
[09:00] <pitti> if it already exists, you can use it
[09:00] <pitti> (exists from a previous SRU, as the package importer created it)
[09:01] <chrisccoulson> can  a shebang be more than 80 characters? i'm guessing not by my thunderbird build error:
[09:01] <chrisccoulson> 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] <pitti> chrisccoulson: it's more likely that the interpreter is missing the +x perm
[09:03] <chrisccoulson> pitti - the interpreter is executable. the interpreter is truncated to 80 characters in the error message though
[09:03] <chrisccoulson> i wonder why i've not hit this in firefox yet :/
[09:03] <pitti> hm, I never heard about such a limitation
[09:03] <chrisccoulson> me neither, that's why i'm confused ;)
[09:04] <chrisccoulson> it seems too much of a coincidence that the shell has truncated it to 80 characters though
[09:04] <Laney> didrocks: yeah, just use a debdiff for SRUs, at least for the first one :(
[09:04] <Laney> morning!
[09:04] <didrocks> Laney: it's accepted right now
[09:04] <didrocks> Laney: so, I want to push my branch :)
[09:04] <Laney> did the importer not create it yet?
[09:05] <pitti> chrisccoulson: confirmed
[09:05] <pitti> $ cp /bin/bash /tmp/`seq -s '' 1 100`
[09:05] <pitti> then I created a /tmp/test.sh with that, and it fails with the same error
[09:05] <chrisccoulson> thanks
[09:06] <pitti> chrisccoulson: hm, running through /usr/bin/env doesn't help either
[09:06] <chrisccoulson> firefox is using python-virtualenv quite extensively throughout the build. that must be fairly close to failing as well
[09:06] <didrocks> Laney: doesn't seem so (compiz on quantal)
[09:07] <pitti> calling /tmp/12345678910<tab> /tmp/test.sh works, though
[09:07] <pitti> chrisccoulson: so you might need to call the interpreter explicitly
[09:07] <didrocks> Laney: and it's the second compiz SRU
[09:07] <Laney> weird black magic
[09:07] <Laney> oh, http://package-import.ubuntu.com/status/
[09:07] <chrisccoulson> pitti, thanks. i'll modify the build system to do that
[09:08] <Laney> maybe a member of ~ubuntu-branches (someone on the TB ...) could do it manually if that wouldn't brea kstuff
[09:08] <didrocks> Laney: ok, I'll ask for it
[09:08] <didrocks> thanks Laney ;)
[09:09] <didrocks> if only I knew someone of the TB
[09:09] <didrocks> oh a pitti! :)
[09:09]  * pitti runs
[09:09] <didrocks> pitti: too late :-) would you mind pushing lp:~didrocks/compiz/quantal to some quantal-proposed branch? :)
[09:09] <universal_tb_pri> oh, that didn't work
[09:09] <didrocks> ahah :)
[09:09] <pitti> /nick universal_tb_priv_command_executor
[09:10] <pitti> didrocks: "some"?
[09:10] <pitti> didrocks: the UDD branch, or some ~ubuntu-core-dev etc. one?
[09:10] <didrocks> pitti: I guess lp:ubuntu/quantal-proposed/compiz is the canonical url?
[09:10] <pitti> ah, so the UDD one
[09:10] <didrocks> yes please :)
[09:11] <didrocks> or is it for ~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed/ for the full url?
[09:11] <pitti> 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] <pitti> bzr: ERROR: Der Server meldete einen unerwarteten Fehler: ('error', 'xmlrpclib.Fault', '<Fault -1: "Unexpected Zope exception: TypeError: (\'Could not adapt\', <SuiteSourcePackage ubuntu/quantal-proposed/compiz>, <InterfaceClass lp.code.interfaces.branchtarget.IBranchTarget>)">')
[09:12] <didrocks> Laney: I think I just discovered yetanotherurl :)
[09:12] <Laney> heh
[09:12] <didrocks> pitti: I think you need to use the full URL first
[09:12] <Laney> that's the "why isn't UDD working?!?!?!" url
[09:12] <didrocks> pitti: at least, that's where I got the "permission denied"
[09:12] <pitti> bzr push bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/quantal-proposed/compiz
[09:12] <pitti> same error
[09:12] <didrocks> Laney: heh ;)
[09:12] <didrocks> ah?
[09:12] <didrocks> even with ~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed/ ?
[09:13] <pitti> $ bzr push lp:~ubuntu-branches/ubuntu/quantal/compiz/quantal-proposed
[09:13] <pitti> that seems to get further
[09:13] <pitti> Packaging branch version: None
[09:13] <pitti> Packaging branch status: OUT-OF-DATE
[09:13] <pitti> Created new stacked branch referring to /+branch-id/673165.
[09:13] <pitti> and done
[09:13] <didrocks> thanks pitti ;)
[09:13] <pitti> bzr branch lp:ubuntu/quantal-proposed/compiz -> still failing, though
[09:13]  * didrocks is trying as well
[09:13] <didrocks> yeah, failing
[09:14] <pitti> didrocks: any reason to not just upload it and let the importer sort it out?
[09:14] <pitti> you can then push --overwrite, to "fix" the history
[09:14] <didrocks> pitti: well, it's been 2 uploads (and 2 months) that the first SRU is released
[09:14] <pitti> but I never found UDD to work well for SRUs
[09:14] <didrocks> pitti: and it was never imported
[09:14] <didrocks> pitti: we use it for the daily build pre-raring (pre packaging-inlining)
[09:15] <Laney> the compiz importer is broken per that URL I gave a minute ago
[09:16] <didrocks> hence we used the pitti-universal_tb_priv_command_executor trick :)
[09:17] <Laney> yeah, just saying that's why 'just upload'ing didn't work :)
[09:19] <maxb> The concept of how the UDD importer should work in concert with packagers who actually *use* UDD too seems sadly fuzzy :-/
[09:20] <maxb> Which makes fixing it rather hard
[09:22] <Laney> it's hard to advocate that people try to use it when there's still roadblocks like these
[09:22] <Laney> 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] <didrocks> I agree
[09:24] <didrocks> that's one (but not the only one) of the reason that we are going with inline packaging for the unity stack
[09:24] <didrocks> (knowing that make dist doesn't distribute the packaging)
[09:25] <chrisccoulson> pitti, oh, it's actually fixed in newer versions of python-virtualenv
[09:25] <chrisccoulson> pitti, https://github.com/pypa/virtualenv/blob/develop/virtualenv.py#L637
[09:26] <maxb> The SRU branch thing is, I guess, something solely needing fixing on the LP side
[09:26] <seb128> chrisccoulson, backport the patch ;-)
[09:26] <maxb> 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] <chrisccoulson> right, trying the build again. hopefully i get a nice shiny testsuite to run at the end of it :)
[09:33] <dholbach> hiya
[09:33] <dholbach> can anyone reply to https://twitter.com/lmukadam/statuses/273548780324925440 please?
[09:36] <seb128> dholbach, salut
[09:37] <seb128> dholbach, no plan to change anything yet, geary is too new to even consider it
[09:38] <dholbach> ok, will reply
[09:38] <chrisccoulson> new and shiny? but that's the only criteria isn't it? ;)
[09:40] <mvo> in raring when I run xvfb-run for my software-center tests I see hangs - anyone lese having trouble with that in raring?
[09:43] <pitti> mvo: not here, seems to work fine; I use xvfb-run in pygobject and apport, and the autopkgtest never failed for those
[09:44] <mvo> pitti: thanks, that is good to know
[09:44] <pitti> 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] <didrocks> jibel: FYI, oif bootstrapped as well (and added more to misc for autopilot and so on)
[10:02] <didrocks> 21 projects are live now
[10:03] <didrocks> 4 indicators are ready, but waiting on tests to be fixed
[10:03] <didrocks> 16 for unity are ready, but waiting on autopilot
[10:18] <mvo> 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] <pitti> $ aptd --dummy --session-bus
[10:20] <pitti> that runs here, how does it fail for you?
[10:21] <mvo> pitti: it runs but it won't stop on sending sigterm
[10:21] <mvo> pitti: that used to work
[10:21] <pitti> killall -TERM aptd
[10:21] <pitti> indeed
[10:21] <pitti> mvo: can you please file a bug about it? that seems to be a rather serious regression
[10:22] <pitti> mvo: on bugzilla preferrably, but LP is okay, too
[10:22] <mvo> pitti: sure, hold on a sec, its not entirely trivial to reproduce, I'm working on a testcase right now
[10:22] <pitti> mvo: but report with apt seems fine; I'll see to writing a test case then
[10:27] <mvo> pitti: https://bugzilla.gnome.org/show_bug.cgi?id=689208
[10:27] <ubot2> Gnome bug 689208 in general "signal handling issues with 3.7 issues" [Normal,Unconfirmed]
[10:27] <mvo> 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] <pitti> mvo: I have an idea
[10:28] <pitti> mvo: danke fuer den report
[10:30] <pitti> mvo: presumably from this tiny commit: http://git.gnome.org/browse/pygobject/commit/?id=191cf45a
[10:31] <pitti> mvo: I'l have a look ASAP
[10:31] <pitti> note, regardless how many tests you write, there is always the n+1st bug
[10:36] <mvo> pitti: heh, so true - it bugs me a bit that I can't write a easy testcase
[10:37] <chrisccoulson> i wonder why kenvandine uploaded the original patch from bug 1076350?
[10:37] <ubot2> 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] <pitti> mvo: I hope that tests/test_mainloop.py test_sigint() written with s/INT/TERM/ will reproduce it
[10:43] <pitti> hm, killing a simple MainLoop with SIGTERM works fine
[10:46] <pitti> mvo: http://paste.ubuntu.com/1394144/ succeeds here; so I guess aptdaemon is doing something slightly more complicated
[10:48] <mvo> 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] <pitti>            import dbus.mainloop.glib
[10:49] <pitti>             dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
[10:49] <pitti> when I add this to the test, it still works
[10:49] <pitti> mvo: ok, I'll keep digging
[10:49] <seb128> chrisccoulson, he likely didn't follow the issue closely enough and picked the first one he crossed
[10:49] <mvo> yeah, same here :/
[10:50] <pitti> [pid  9375] --- SIGTERM (Terminated) @ 0 (0) ---
[10:50] <pitti> [pid  9375] rt_sigreturn(0xf)           = -1 EINTR (Interrupted system call)
[10:50] <pitti> mvo: ^ that's what strace shows me in apt; EINTR sounds fishy
[10:51] <mvo> pitti: indeed, same here
[10:53] <pitti> oh, old pygobject apparently installed a signal handler for all signals, not just SIGINT
[10:54] <pitti> so this seems to be a GLib thing which previously has been shadowed by a pygobject hack
[10:54] <mvo> pitti: so its all desrt fault?
[10:55] <pitti> so in a way this brings current pygobject closer to the glib behaviour, but is of course a behavioural change
[10:56] <pitti> hm, but even if I do install a SIGTERM handler, it's not being called
[10:57] <pitti> hm, aptdaemon does a lot of signal handling by itself, RTFS
[10:57] <pitti> ./aptdaemon/core.py:        signal.signal(signal.SIGTERM, self._sigquit)
[11:00] <pitti> mvo: ^ when I comment this out, it works
[11:00] <pitti> (it doesn't call its .Quit(), of course)
[11:02] <mvo> pitti: right
[11:03] <mhr3> why don't you use glib's signal sources?
[11:03] <mhr3> they play nice with mainloop
[11:04] <mvo> mhr3: no reason really, let me see if that fixes it
[11:05] <mvo> mhr3: well, except "introspectable="0"" in g_unix_signal_add
[11:05] <pitti> unix_signal_add_full()
[11:05] <mvo> cool
[11:06] <pitti> this is missing an annotation in glib to expose itself as unix_signal_add
[11:08] <mvo> 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] <mvo> oh, no
[11:10] <mvo> if used correct it seems to be fine *cough*
[11:11] <pitti> mvo: FYI: http://git.gnome.org/browse/glib/commit/?id=fca30c3e165d
[11:11] <mvo> pitti, mhr3: thanks, I prepare a branch for that, regardless of the bug this is cleaner to use
[11:11] <mvo> pitti: \o/
[11:11] <pitti> mvo: that will break a call to _full(), though
[11:12] <pitti> but it's more consistent that way with the other API
[11:12] <mvo> pitti: I'm not sure I understand, can I still ue _full() ?
[11:12] <pitti> no, that'll be unix_signal_add() then
[11:13] <mvo> pitti: ok, so I will prepare the branch and note that it needs a later pygobject
[11:13] <pitti> that's a bit of a problem with "Rename to:"
[11:13] <pitti> mvo: not pygobject, but gobject-introspection (which ships the GLib .gir)
[11:13] <pitti> c'est difficile :(
[11:13] <mvo> pitti: could there be a compat interface? i.e. deprecation warning but still providing the other name?
[11:14] <pitti> yes, I can add an override
[11:14] <mvo> pitti: other people might use _full() already, no?
[11:16] <mvo> 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] <pitti> right, SIGQUIT doesn't seem to work either
[11:17] <pitti> mvo: that's Ctrl+\
[11:17] <pitti> not that big of a deal, I guess
[11:18] <mvo> pitti: yeah
[11:18] <mvo> (thats what I meant with esoteric :)
[11:21] <pitti> mvo: http://git.gnome.org/browse/pygobject/commit/?id=e45c690bc83b6d513887649de88965a9752e316d
[11:23] <mvo> pitti: https://code.launchpad.net/~mvo/aptdaemon/use-glib-unix-signal-handling/+merge/136626 <- if that looks ok I will merge/upload
[11:23] <mvo> pitti: nice!
[11:24] <pitti> LGTM, MP updated
[11:24] <pitti> as for the bugzilla report, I'm still not quite sure what happens here
[11:24] <pitti> so glib does something funky with signals, and aptdaemon re-routes it
[11:25] <pitti> 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] <pitti> mvo: hm, I installed 3.4.2, and that didn't work either
[11:26] <pitti> oh, I'm sorry; I had a hacked source
[11:26] <pitti> it does
[11:26] <mvo> :)
[11:27] <pitti> mvo: so because the old pygobject installed a signal watch pipe, aptdaemon's signal handler got enabled
[11:27] <pitti> fun
[11:30]  * mvo prepares upload
[11:36] <pitti> 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] <mlankhorst> seb128: no irc log in the weekly summary?
[12:15] <davmor2> hey guys is there a way to enable fglrx without Unity disappearing from the desktop in Quantal yet?
[13:15] <mvo> 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] <pitti> mvo: fun, so */ was handled, but not /* ?
[13:17] <mvo> pitti: yeah, I was a bit puzzled by this too
[13:17] <pitti> +1ed
[13:18] <mvo> \o/
[13:21]  * Laney uploads a test gstreamer 1.0 package
[13:22] <Laney> brasero
[13:23] <desrt> yawn
[13:23] <Sweetshark> 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] <ubot2> Launchpad bug 595910 in Launchpad itself "Forbidden error on +participation" [High,Fix released] https://launchpad.net/bugs/595910
[13:23] <seb128> Laney, \o/
[13:23] <seb128> desrt, hey
[13:23] <desrt> hi
[13:24] <Laney> it's the smallest impact one I could find (no -good dep)
[13:24] <seb128> Sweetshark, how much change does that update contain? wouldn't it be a good idea to test it? ;-)
[13:24] <Laney> so should let us promote the main libraries
[13:24] <seb128> Laney, cool
[13:27] <Sweetshark> 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] <seb128> Sweetshark, ok
[13:31]  * desrt kicks off morning jhbuildage
[13:33] <seb128> Sweetshark, uploaded
[13:33] <didrocks> hey desrt
[13:34] <didrocks> long time no see ;)
[13:34] <desrt> didrocks: :)
[13:34] <Laney> done
[13:34]  * Laney is scared now
[13:35] <Sweetshark> seb128: thx
[13:35] <seb128> Sweetshark, yw!
[13:36] <Laney> if someone wants to promote gst-plugins-base1.0 to main it should be able to build right away
[13:42] <tjaalton> 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] <tjaalton> this after reboot
[13:42] <tjaalton> lightdm restart makes it normal again
[13:43] <seb128> Sweetshark, Rejected:
[13:43] <seb128> 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] <seb128> Sweetshark, you probably want to target precise-proposed rather than quantal?
[13:44] <seb128> tjaalton, not sure, seems like a vt race between xorg/plymouth/lightdm?
[13:44] <tjaalton> plymouth isn't used in this case, ruled it out
[13:44] <tjaalton> also, when I vt change the mouse is still there..
[13:45] <tjaalton> 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] <seb128> Laney, I will have a look in a bit if didrocks, with his MIR hat, doesn't beat me
[13:46] <seb128> theorically it's a MIR team job ;-)
[13:47]  * didrocks feels no social pressure
[13:47] <seb128> tjaalton, thanks
[13:47] <seb128> didrocks, not at all
[13:47] <seb128> ;-)
[13:47] <Laney> I don't think it needs it as 0.10 is already in main
[13:47] <Laney> at least infinity promoted the main gstreamer1.0 package on that basis
[13:47] <seb128> Laney, susssh, don't ruin my plan :p
[13:47] <Laney> :P
[13:47] <didrocks> I'll just promote I guess after a quick look
[13:48] <Laney> lunch → to the running shoe shop
[13:48]  * Laney fears for his heart and lungs
[13:48] <didrocks> Laney: enjoy!
[13:54] <Sweetshark> seb128: dah, indeed. brainfart.
[13:55] <Sweetshark> seb128: fixing
[13:55] <seb128> Sweetshark, thanks
[13:55] <pitti> chrisccoulson: hm, where can I see firefox' cookie blacklist?
[13:56] <pitti> chrisccoulson: I removed some, and now firefox apparently automatically blacklisted the site I was removing cookies for
[13:56] <pitti> and I can't figure out how to get them back
[13:56] <chrisccoulson> pitti, permissions.sqlite
[13:56] <kenvandine> didrocks, yay for seeing the first autolanding for webapps :)
[13:57] <pitti> oh is that network.cookie.blockFutureCookies ?
[13:57] <pitti> (in about:config)
[13:57] <pitti> chrisccoulson: ^ that's "true" for me now
[13:57]  * pitti resets it
[13:57] <didrocks> kenvandine: yeah \o/
[13:57] <didrocks> kenvandine: now your turn to bootstrap all the stack we are confident with! :)
[13:58] <kenvandine> i manually did the last release of unity-firefox-extension just to get fixes out there
[13:58] <pitti> chrisccoulson: ah, so there's no UI for this?
[13:58] <chrisccoulson> pitti, i'm not even sure that setting is used anywhere
[13:58] <pitti> no, still doesn't work
[13:59] <seb128> kenvandine, hey, speaking of which, chrisccoulson suggested you took the wrong version of the patch you applied to it
[13:59] <kenvandine> oh?
[13:59] <kenvandine> i took what was merged into trunk
[13:59] <seb128> chrisccoulson, <chrisccoulson>	i wonder why kenvandine uploaded the original patch from bug 1076350?
[13:59] <ubot2> 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] <didrocks> kenvandine: so maybe we can have an automated one for the fix? :)
[14:00]  * didrocks sees that as an opportunity
[14:00] <kenvandine> chrisccoulson, i took rev 348
[14:00] <Sweetshark> seb128: just for completeness: should the last-version in genchanges be the last successful -proposed upload, or the last successful precise upload?
[14:00] <kenvandine> so i guess they merged the wrong version of the fix
[14:01] <seb128> Sweetshark, the current version in -updates
[14:01] <Sweetshark> seb128: k
[14:01] <Sweetshark> seb128: then it was right for a change ;)
[14:01] <seb128> Sweetshark, e.g you want to list everything > 1:3.5.4-0ubuntu1.1
[14:02] <kenvandine> oh... that was the CVE
[14:02] <Sweetshark> seb128: yep
[14:02] <kenvandine> that was the version that mdeslaur uploaded
[14:02] <kenvandine> i didn't modify the patch
[14:07] <mdeslaur> 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] <kenvandine> hey mdeslaur
[14:07] <mdeslaur> kenvandine: hi!
[14:07] <mdeslaur> kenvandine: I'm a bit confused :)
[14:07] <kenvandine> it hasn't been merged into trunk yet
[14:07] <kenvandine> https://code.launchpad.net/~zaspire/unity-firefox-extension/listen-tab-close/+merge/135266
[14:07] <kenvandine> i am too :)
[14:07] <pitti> chrisccoulson: ok, "select * from moz_hosts where type = 'cookie';" did the trick
[14:08] <pitti> chrisccoulson: I'm sure my mother could figure this out :)
[14:08] <mdeslaur> kenvandine: ah, yes, chrisccoulson told me that was the wrong one
[14:08] <mdeslaur> kenvandine: the right fix is r350..351 from here: https://code.launchpad.net/~chrisccoulson/unity-firefox-extension/lp1076350
[14:09] <kenvandine> ah
[14:09] <chrisccoulson> of course, the right, right fix would be to rewrite it to stop attaching document specific objects to the outer window :)
[14:09] <kenvandine> so the other branch shouldn't get merged
[14:10] <kenvandine> someone should kill that MP :)
[14:10] <kenvandine> chrisccoulson, is it worth another upload to change that?
[14:10] <chrisccoulson> kenvandine, not really. i suspect that would be a much bigger change tbh
[14:10] <kenvandine> ok
[14:11] <kenvandine> well i need to relocate to the car dealership, getting work done :)
[14:11] <chrisccoulson> and if you asked me to do that, i'd probably just start from scratch ;)
[14:11] <kenvandine> hehe :)
[14:11] <kenvandine> i'll be back in ~20-30m
[14:12] <chrisccoulson> pitti, there are some issues atm (see https://bugzilla.mozilla.org/show_bug.cgi?id=814554)
[14:12] <ubot2> Mozilla bug 814554 in General "Firefox 17 silently stops processing permissions.sqlite when rejecting rules valid under Firefox 16" [Normal,Assigned]
[14:12] <chrisccoulson> yours seems like the opposite problem though ;)
[14:13] <Sweetshark> seb128: I dont need to version bump as this was rejected anyway, right?
[14:13] <seb128> Sweetshark, correct, you never need to bump version for things that don't leave the queue
[14:13] <seb128> Sweetshark, queue doesn't count, you can have several times the same version in it
[14:16] <Sweetshark> seb128: I guessed so, but still a bit uncertain as I never do the sponsoring ...
[14:31] <Sweetshark> 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] <seb128> Sweetshark, ok
[14:52] <didrocks> 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] <Laney> didrocks: merci!
[15:04] <didrocks> de rien :)
[16:16] <mvo> 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] <pitti> mvo: right, that one already has a Rename:
[16:17] <pitti>     <function name="io_add_watch_full"
[16:17] <pitti>               c:identifier="g_io_add_watch_full"
[16:18] <pitti>               shadows="io_add_watch">
[16:18] <pitti> in /usr/share/gir-1.0/GLib-2.0.gir
[16:19] <mvo> 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] <seb128> 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] <pitti> mvo: no, those are global constants, not enums (historical reasons?)
[16:20] <pitti> mvo: i. e. GLib.PRIORITY_HIGH is fine
[16:20] <mvo> pitti: aha, ok
[16:41]  * Sweetshark realizes he still reads "historical reasons" as "hysterical reasons" from his OpenOffice.org times ....
[17:20] <mspencer> mpt: I have another question regarding Contributor Console.
[17:33] <achiang> 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] <achiang> kenvandine: ^^ ??
[17:34]  * kenvandine looks
[17:35] <kenvandine> charles, larsu: i assume one of you are looking after appmenu-gtk right?
[17:35] <kenvandine> oh, that's a backport
[17:35] <achiang> right
[17:35]  * charles looks
[17:35] <achiang> the fix is already in trunk
[17:35] <kenvandine> so you want to SRU that to precise?
[17:35] <achiang> but it never got into precise
[17:36] <achiang> correct
[17:36] <achiang> i want to SRU into precise
[17:36] <charles> kenvandine: yes, that's one of mine
[17:36] <kenvandine> cyphermox, ^^ appmenu-gtk is your package right?
[17:36] <charles> IMO it's likely safe for backport
[17:36] <cyphermox> rawr
[17:37] <cyphermox> "my" package ;)
[17:37] <kenvandine> hehe :)
[17:37] <charles> in balance tho, it's a smallish leak
[17:37] <cyphermox> charles: doesn't take much if it gets called a lot
[17:37] <cyphermox> achiang: I'll take care of it
[17:37] <charles> plus, it's fixed in Q with no complaints so far
[17:37] <seb128> it's not a trivial diff
[17:37] <charles> so I'd say go for it
[17:37] <achiang> charles: anything we can do to fix #780602 would help
[17:37] <kenvandine> charles, do you know if there are other fixes in the 0.4 branch worthy of SRU?
[17:38] <seb128> bug #780602
[17:38] <ubot2> Launchpad bug 780602 in network-manager-applet (Ubuntu Precise) "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602
[17:38] <charles> kenvandine: let me look at the changelog...
[17:38] <achiang> cyphermox: i can prepare a debdiff to get another upload credit... ;)
[17:39] <cyphermox> achiang: yes, that can help
[17:39] <achiang> ok, well, i guess i'll wait for charles to accept the MP first
[17:40] <charles> kenvandine: no, nothing else SRU worthy. not many changes in that package last cycle
[17:41] <achiang> so in general, what is the process for doing SRUs when an upstream branch exists too? send MP for branch, wait for it to get accepted, then create a debdiff, subscribe ubuntu-sponsors, then do SRU paperwork?
[17:42] <didrocks> achiang: right, it's the best workflow (but will change for raring and going on ;))
[17:42] <didrocks> frmo*
[17:42] <didrocks> from*
[17:42] <charles> achiang: you'll want to pull in r160 as well
[17:42] <seb128> Laney,
[17:42] <Laney> I saw!
[17:42] <achiang> didrocks: thanks. hopefully it will get simpler in raring. :)
[17:43] <achiang> charles: ah, ok
[17:43] <seb128> Laney, ;-)
[17:43] <charles> achiang: that undoes g_debug() call in r158 that was too noisy
[17:43] <didrocks> it definitively will :)
[17:43] <achiang> charles: thanks
[17:43] <Laney> building good now
[17:43] <seb128> Laney, thanks
[17:43] <Laney> you could promote it as-is
[17:43] <Laney> it just misses some other plugins, but nothing brasero needs afaik
[17:43]  * seb128 looks at didrocks :p
[17:43] <seb128> didrocks, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ... see what you did, didn't promote gst-good :p
[17:43] <didrocks>  /quit toooooooooooooo late :-)
[17:44] <charles> achiang: ping me after you update and I'll approve it
[17:44] <achiang> charles: ack, thx
[17:44] <didrocks> seb128: I promoted what I was aked to promote TBH :p
[17:44] <Laney> is true, I didn't think it was good
[17:44] <seb128> not good enough it seems
[17:45] <Laney> badum tish
[17:45] <didrocks> right, but not ugly
[17:46] <didrocks> so we miss gstreamer1.0-pulseaudio
[17:49]  * seb128 kicks firefox
[17:49] <seb128> not listing the first awesome bar result in the popdown sucks, please give me that back rather than trying to be smart and autofile the entry
[17:49] <didrocks>  * libpng-dev does not exist (pure virtual?)
[17:49] <didrocks> Laney: ^?
[17:50] <Laney> it probably is pure virtual
[17:50] <didrocks> Laney: how the build-dep is working then? :)
[17:50] <Laney> libpng12-dev is in main
[17:51] <didrocks> Laney: libpng doesn't provide/have a package for libpng-dev
[17:52] <didrocks> this is an issue on building, right?
[17:52] <Laney> no, libpng12-dev Provides libpng-dev
[17:52] <Laney> check the build log, it gets it right
[17:52] <didrocks> weird, so deps aren't matched for installing a new package, but for build-deps it's fine?
[17:53]  * didrocks is puzzled
[17:55] <didrocks> Laney: do you know about this? (the logs looks good, but I wanted to know how this perform this magic) ^
[17:56] <Laney> It's part of the contract that libpng provides
[17:56] <Laney> a 'libpng-dev' pure virtual package that is guaranteed to only be provided by one real -dev package
[17:56] <Laney> so that they can transition by changing the provides to libpng13-dev in future and every build-depending package doesn't have to be updated
[17:57] <Laney> (won't work if you want a versioned BD though, as Provides are versionless, so in that case you have to use the real package name)
[17:58] <didrocks> Laney: interesting, I didn't know there was a special case for a provides to be only done by one package
[17:58] <didrocks> Laney: for that you just have one in the whole archive and it's enough? or you have more magic?
[17:59] <didrocks> (doesn't seem from the packaging)
[17:59] <Laney> I'm not sure what happens if there are multiple providers
[17:59] <didrocks> yeah, I knew about the version-less, didn't know that this case was handled
[17:59] <Laney> perhaps apt just arbitrarily chooses one to install
[17:59] <didrocks> Laney: I guess, it's the same than for the deps case: it will tell you that there is no candidate
[18:00] <Laney> or maybe it's an error
[18:00] <didrocks> anyway, everything is good
[18:00] <didrocks> promoting the missing stack
[18:00] <Laney> awesome
[18:01] <didrocks> (done)
[18:02] <Laney> :-)
[18:02] <Laney> tomorrow I'll push the big stack
[18:02] <didrocks> sweet!
[18:02] <Laney> after moving the rest of the plugins to good and filing bugs on at-risk packages
[18:03] <Laney> hopefully won't require any more promotions
[18:03] <didrocks> Laney: if you need, do not hesitate, it's quite quick for those
[18:07] <achiang> charles: pulled in r160 too
[18:14] <charles> achiang: thanks, approved
[18:14] <achiang> charles: thanks! do you merge it or do i?
[18:17] <charles> achiang: I /think/ the bot will do it, though I'm not positive that it watches the older branches for merges
[18:18] <charles> achiang: if nothing happens, I'll merge it manually
[18:20] <achiang> charles: ok, thanks
[18:37]  * didrocks waves good evening
[18:37] <seb128> didrocks, 'night
[18:37] <didrocks> seb128: you too! if autolanding works fine, you'll have a lot of packages to NEW tomorrow :)
[18:37] <seb128> I will keep an eye open for that ;-)
[18:37] <didrocks> you'll need 2 I guess :p
[18:38] <micahg> umm, I thought stuff that required NEW wouldn't be autouploaded
[18:38] <seb128> I will open the second once the first one see something moving :p
[18:38] <didrocks> micahg: why? It's ending up in the NEW queue
[18:38] <didrocks> micahg: why would you care the way it was uploaded to ubuntu?
[18:38] <micahg> didrocks: well, I was under the impression that debian dir changes required review before auto uploading
[18:39] <didrocks> micahg: it does
[18:39] <didrocks> micahg: and a manual hack
[18:39] <micahg> ah, ok
[18:39] <didrocks> ack*
[18:39] <didrocks> so it will go through this process where I have to rerun the publisher manually
[18:39] <didrocks> (even if I already ack the changes before adding the project to the stack)
[18:40] <didrocks> so basically acking my ack ;) and then, as usual, having another archive admin to NEW it
[19:26] <achiang> cyphermox: https://bugs.launchpad.net/ubuntu/+source/appmenu-gtk/+bug/787736
[19:26] <ubot2> Launchpad bug 787736 in appmenu-gtk (Ubuntu) "RebuildData structs are leaked in rebuild() / do_rebuild()" [Medium,Fix released]
[19:36] <Sweetshark> raring daily image fails with 'a general error when mounting filesystems'. Known issue?
[19:36] <cyphermox> achiang: cool, thanks. I'll get to it right aster I'm done grabbing data from this modem
[19:36] <achiang> cyphermox: thanks!
[19:38] <Sweetshark> achiang: do you have a minute?
[19:38] <achiang> Sweetshark: sure
[19:44] <jbicha> Laney: we need a grilo MIR before uploading Totem 3.6
[19:49] <seb128> or to disable the option?
[19:52] <cyphermox> achiang: patch looks odd to me. are you sure that typedef struct _RecurseContext gets removed and really should be? I see it being removed but no removals of any reference to it
[19:53] <achiang> cyphermox: i'll double-check it
[19:54] <cyphermox> I looked fast
[19:57] <achiang> cyphermox: might take me a bit
[20:01] <achiang> cyphermox: ok, so removing _RecurseContext was commit r152.3.1 in trunk, which is "remove dead code" so it was never used anyway
[20:02] <achiang> cyphermox: i cherrypicked the entire r158 patch, which had a cleanup in it, i guess (and was what was eventually merged into trunk)
[20:03] <achiang> cyphermox: does that make sense? it's more obvious if you use bzr qlog on trunk, and expand r158
[20:03] <cyphermox> well, np
[20:10] <cyphermox> fair enough, it is indeed dead code
[20:16] <cyphermox> I don't like patchless packages
[20:18] <cyphermox> achiang: there is already a appmenu-gtk in precise-proposed, it was uploaded 2 hours ago
[20:18] <cyphermox> https://launchpad.net/ubuntu/+source/appmenu-gtk/0.3.92-0ubuntu1.1
[20:19] <jbicha> seb128: Laney: oh ok, I had trouble building without grilo earlier but it works now
[20:19] <achiang> cyphermox: d'oh. i guess i'll respin with a new version?
[20:19] <achiang> cyphermox: or rather, what is the protocol here?
[20:19] <cyphermox> achiang: could you? then we'll have to deal with making sure they all get acked
[20:20] <cyphermox> could be verification-failed and re-uploaded with all the fixes together I guess
[20:20] <achiang> cyphermox: so: download 1.1 from -proposed, refresh my diff, re-test, then attach new debdiff with 1.2 version string?
[20:20] <cyphermox> since it's a recent upload and not something that's been sitting in proposed for weeks
[20:21] <cyphermox> yeah, there's a procedure for this but I can't remember all the details...
[20:22] <achiang> ubuntu development is somewhere between linux-kernel and hpux kernel in development complexity/process ;)
[20:24]  * Sweetshark starts a VM with 24GB RAM and 32 cores on his desktop. Yep -- works.
[20:24] <Sweetshark> .oO(... and thus that machine has more RAM than discspace)
[20:28] <xnox> Sweetshark: that will fail to install ubuntu-desktop as it will try to allocate 24GB for swap and fail the install
[20:28] <cyphermox> achiang: it's that you don't want to just kill off the sru that is already in "progress", but at the same time you don't have to wait 7+ days for it to be verified and make it to -updates, and since it's SRUs all the individual changes need to be verified ;)
[20:31] <achiang> cyphermox: so, what should i do? this is ... hard :)
[20:34] <Sweetshark> xnox: hum, seemed to have worked out. lemme check that.
[20:34] <xnox> Sweetshark: as in, ubiquity install should/will fail
[20:35] <xnox> installer
[20:36] <Sweetshark> xnox: I just clicked though the installer (12.10) and got 4.3G / and 11G /home but no swap.
[20:37] <xnox> Sweetshark: did you do any funny preseeding? (and this is with ubuntu desktop cd / ubiquity or something else?)
[20:37] <seb128> Sweetshark, that's weird, clicking through the installer shouldn't give you a separate user dir
[20:37] <xnox> I was expecting you to experience a Laney classic bug 1066964
[20:37] <ubot2> Launchpad bug 1066964 in ubiquity (Ubuntu) "Auto partitioner can create a root partition which is too small" [High,Confirmed] https://launchpad.net/bugs/1066964
[20:38] <Sweetshark> xnox: vanilla 12.10 desktop amd64 cd ..
[20:39] <Sweetshark> xnox, seb128: ahh, I have an idea what happened ... although .... hmmm ...
[20:39] <xnox> Sweetshark: zfs or btrfs used by any chance?
[20:39] <xnox> that's the two conditions when it would do that....
[20:39] <xnox> Sweetshark: or did you "accidently" use the upgrade option?
[20:40] <Sweetshark> xnox, seb128: I used the 13.04 daily and it failed with 'general mount error', before it did even show a desktop. OTOH it shouldnt have touched the disc at that point?
[20:41] <jbicha> pitti's not still here, is he?
[20:41] <xnox> Sweetshark: i can see that message as well, did not troubleshoot yet, but it does bring up the installer after showing that warning.
[20:42] <jbicha> totem's not recognizing that python-gobject-dev is installed http://paste.ubuntu.com/1395386/ http://git.gnome.org/browse/totem/tree/configure.in?h=gnome-3-6
[20:42] <Sweetshark> xnox: so insert 13.04 daily, fail before seeing any desktop, insert 12.10 final, click through ..
[20:43] <xnox> Sweetshark: from the installed system can you do `ubuntu-bug ubiquity` that will upload the logs for me to inspect =)
[20:45] <cyphermox> achiang: just prepare your debdiff with the version being 1.2, I think the rest I can fix with how I build the package after
[20:45] <cyphermox> seb128: what's the procedure to supersede the appmenu-gtk you sponsored earlier ? :)
[20:45] <cyphermox> (for precise sru)
[20:47] <Sweetshark> xnox: do you need the debug log (which includes the password)?
[20:47] <seb128> cyphermox, talk to slangasek but we already jointed several updates so I think it's "do an update on top of the current one and wait a week"
[20:47] <cyphermox> seb128: right, so that's what I thought
[20:47] <xnox> Sweetshark: which has no passwords unless booted with debug-ubiquity.
[20:47] <seb128> just put it in the queue
[20:47] <xnox> Sweetshark: not really =)
[20:48] <seb128> it will stay there until the current one goes to updates
[20:48] <xnox> Sweetshark: we have no way to tell if the debug has or has not the passwords, hence the warning.
[20:48]  * xnox should fix that
[20:48] <cyphermox> would mostly be a matter or taking that debdiff and uploading by building as bzr bd -- -V$version-in-release)
[20:48] <seb128> talk to slangasek if you want that extra fix included in the same run
[20:48] <cyphermox> ok
[20:49] <seb128> otherwise take the current queued update, applied you diff, debuild -S and upload
[20:49] <seb128> it will just take a week until it's reviewed
[20:49] <seb128> well, if you are lucky
[20:49] <Sweetshark> xnox: ok, so you dont need the log, thus Ill click 'no' to not include the log.
[20:49] <seb128> the queue backlog is rather 3 weeks
[20:49] <cyphermox> seb128: yeah ;)
[20:51] <cyphermox> achiang: ok to wait ~1 week or is this rush and a Canonical priority? ;)
[20:52] <achiang> cyphermox: no rush, except my own personal one. ;)
[20:52] <Sweetshark> .oO(having a password longer than a fscking windoze activation key sucks when reporting bugs from a VM)
[20:52] <achiang> sick of nm-applet going out to lunch! :)
[20:52] <cyphermox> ok ;)
[20:53] <cyphermox> so we'll wait after this batch of updates gets through to -updates. it shouldn't take too long to get verified
[20:53] <achiang> cyphermox: works for me
[20:55]  * cyphermox takes this opportunity to travel back home while it's not yet a bad storm outside
[20:55] <cyphermox> back later.
[20:56] <cyphermox> seb128: is the Notes backport planned to hit quantal too?
[20:59] <jbicha> maybe the pygobject problem is related to it being multiarched today?
[21:01] <notgary> I'm trying to find out who MCR1 is. I'd never met them before the paper cuts meeting last week, and i'd like to get in touch with them regarding their work on the paper cuts project. Could someone please point me towards their Launchpad profile? My internet stalking skills seem to be failing me tonight :P
[21:02] <Sweetshark> xnox: bug 1084249 -- note that I didnt exactly took care on reproducability during install ....
[21:03] <xnox> Sweetshark: cannot see that bug. Assign it to me?
[21:04] <Sweetshark> xnox: you are?
[21:04] <Sweetshark> xnox: subscribing you in addition, does it help?
[21:04] <xnox> Sweetshark: it did =)
[21:09] <xnox> Sweetshark: this is very strange....
[21:11] <jbicha> notgary: https://launchpad.net/~mc-return
[21:12] <notgary> jbicha: Excellent! Thanks a lot :)
[21:15]  * Sweetshark wondered why his machine had some latency. turns out the jenkins on the host started a (-j32) libreoffice build while the VM had 24GB and 32cores alloced, I guess that explains it.
[21:17] <qengho> Sweetshark: "some latency"? Ow.
[21:19] <Sweetshark> qengho: well, I had to restart mplayer once as the stream was choking. Although that might just have been suboptimal trafficshaping with upgrading/downloading to raring from the VM.
[21:20] <Sweetshark> qengho: chucking along nicely at load average ~ 60
[21:21] <qengho> I'm envious.
[21:23] <Sweetshark> qengho: doing a libreoffice build from scratch in 18 minutes is nice. in 3-4 with a warm ccache is even nicer. (both in tmpfs)
[21:26] <Sweetshark> qengho: 24 minutes (not in tmpfs), while having a 24GB RAM VM upgrading to raring in the background.
[21:45] <xnox> Sweetshark: how long does a qemu-armhf build take?
[21:46] <Sweetshark> xnox: havent tried yet.
[21:47] <Sweetshark> xnox: I can report back in day or so ... gotta run now.
[21:48] <xnox> ack
[22:05] <jbicha> desrt: I'm thinking about having the GNOME Remix use Software Center instead of gpk
[22:05] <xnox> \0/
[22:23] <kenvandine> RAOF_, ping
[22:23] <kenvandine> RAOF_, when you get a chance, can you please look at the gwibber SRU for precise?  it's been waiting in unapproved since october
[22:24] <kenvandine> RAOF_, yesterday i looked for it in the queue and didn't see it, so i uploaded it again... then i found it :)
[22:24] <kenvandine> so it is there twice
[22:33] <mlankhorst> haha
[22:55] <soind> xist side-by-side?
[22:56] <soind> I was logging in to ask if the longterm plan is for Ubuntu to do away with the global menu in favor of HUD, or if they will exist side-by-side?
[22:56] <soind> I personally would like the option of using both.
[23:19] <soind> I was logging in to ask if the longterm plan is for Ubuntu to do away with the global menu in favor of HUD, or if they will exist side-by-side?
[23:31] <desrt> jbicha: that makes senes
[23:40] <Sweetshark> whats the canonical way to make a qemu-armhf build now? I find lots of docs that are outdated and tried qemu-debootstrap --arch armhf quantal eapi-chroot, which fails by not being able to download procps and python3
[23:42] <jbicha> Sweetshark: isn
[23:42] <jbicha> Sweetshark: isn't the "Canonical" way to use the pandaboard they give away to developers?
[23:43] <Sweetshark> jbicha: 22:44 < xnox> Sweetshark: how long does a qemu-armhf build take?
[23:44] <jbicha> I wish I knew how to set up my sbuild to do armhf builds
[23:44] <xnox> Sweetshark: mk-sbuild --arch armhf raring
[23:44] <Sweetshark> jbicha: which is a valid question when you have a 32GB RAM, 32 core amd64 machine and do libreoffice builds regularly ...
[23:44] <xnox> Sweetshark: sbuild -A -d raring --host armhf --build armhf
[23:45] <xnox> path_to.dsc
[23:45] <xnox> jbicha: ^^^^^
[23:46] <xnox> Sweetshark: jbicha: one can also use pbuilder-dist --arch armhf, but that is slower than sbuild
[23:46] <Sweetshark> xnox: thanks. someone who knows about the stuff should go feral on the wiki and kill all the obsolete crap like rootstock, qemu-debootstrap, etc. ...
[23:46] <xnox> Sweetshark: ack will point it out.
[23:47] <xnox> Sweetshark: I presume google will find the rootstock & qemu-deboostrap references for me right?!
[23:47]  * xnox never heard of above mentioned pieces of software
[23:48] <jbicha> xnox: oh, that's easier than the way I was setting up sbuild: http://wiki.debian.org/sbuild thanks :)
[23:48] <xnox> jbicha: yeah, mk-sbuild rocks compared with "typical" way of setting it up.
[23:49] <xnox> jbicha: and it's available on debian, and it works with ubuntu&debian out of the box, and it supports native, qemu-native and cross compilation.
[23:49] <Sweetshark> xnox: well, google found them for me: https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap, https://wiki.ubuntu.com/ARM/RootfsFromScratch, https://wiki.ubuntu.com/ARM/RootStock where still high hits for me on a "ubuntu qemu arm" search
[23:50] <xnox> along with --eatmydata and --vg myexternalvolumegroup
[23:50] <xnox> Sweetshark: *shrug* thanks.
[23:50] <Sweetshark> xnox: the are marked deprecated, but google doesnt seem to bother.
[23:51] <xnox> Sweetshark: I'll write something up and re-direct people.
[23:52] <Sweetshark> https://wiki.ubuntu.com/ARM also still points there.