[03:29] <pitti> Good morning
[05:00] <jbicha> robert_ancell: hey
[05:00] <robert_ancell> jbicha, hello
[05:01] <jbicha> I actually uploaded evince 3.5.2-0ubuntu5 a few minutes ago
[05:02] <robert_ancell> jbicha, but the changes aren't in bzr?
[05:04] <jbicha> when I read evince's NEWS, I thought it would require GTK 3.6, but I guess I just read it wrong
[05:11] <jbicha> ok, pushed the merged branch & a 3.5.3-0ubuntu1
[05:11] <jbicha> *ubuntu2
[05:43] <rickspencer3> good morning pitti, et al
[05:44] <pitti> hey rickspencer3
[06:30] <didrocks> good morning
[06:31] <pitti> bonjour didrocks
[06:32] <didrocks> guten morgen pitti, how are you?
[06:32] <pitti> quite fine, thanks!
[06:32] <pitti> debugging glib on my shiny new Panda board :)
[06:34] <didrocks> heh, I looked at your diff for testing :)
[06:34] <didrocks> so, it means that you have the -dev package installed in the QA infra, right?
[06:37] <pitti> didrocks: debian/tests/control pulls it in as a dependency
[06:38] <didrocks> ah ok ;)
[06:42] <pitti> didrocks: when you don't specify any Depends:, it will install all binaries built by the tested source, FYI (which is the same as Depends: @)
[06:45] <didrocks> oh, seems handy :)
[07:47] <BigWhale> Good Morning Everyone
[07:50] <didrocks> hey BigWhale
[07:50] <seb128> hey
[07:52] <BigWhale> Hello didrocks, seb128. :)
[07:52] <seb128> hey BigWhale, didrocks
[07:52] <didrocks> salut seb128!
[08:51] <mlankhorst>  /11
[09:12] <chrisccoulson> good morning everyone
[09:14] <chrisccoulson> has anybody ever used the feature we add to firefox to choose which plugins handle a particular content type? (Tools -> Manage Content Plug-ins)
[09:29] <chrisccoulson> ok, i'll take that as a "no" :)
[09:29]  * chrisccoulson prepares axe
[09:34] <didrocks> hey chrisccoulson, how are you?
[09:34] <chrisccoulson> hi didrocks
[09:34] <didrocks> I didn't
[09:34] <chrisccoulson> i'm good thanks. how are you?
[09:34] <didrocks> I'm fine, thanks, a little bit hot here ;)
[09:34] <seb128> hey chrisccoulson
[09:35] <seb128> chrisccoulson, I never used the content type stuff no
[09:35] <chrisccoulson> seb128, that's good, i've just killed it now ;)
[09:35] <seb128> lol
[09:35] <chrisccoulson> it relies on a patch which needs rewriting because of an upstream change
[09:35] <seb128> oh, it was an ubuntu thing?
[09:35] <chrisccoulson> and i don't want to waste cycles on something that nobody uses :)
[09:36] <chrisccoulson> seb128, yeah. it's an ubufox feature actually, but it requires changes in firefox to work as well
[09:36] <didrocks> that's an opinionated decision, I like that! :)
[09:37] <seb128> the less cruft to maintainer the better!
[09:38] <chrisccoulson> yeah, i like dropping our changes. i'd like one day to be at zero patches :)
[09:38] <chrisccoulson> perhaps i should adopt a policy whereby anybody who requests an ubuntu modification to firefox has to suggest an existing modification to be removed ;)
[09:40] <didrocks> that's a fair trade ;)
[09:54] <xclaesse> seb128, FYI, I just pushed a patch in empathy-3-4 (and master) to fix the empathy-chat crash when starting a chat
[09:55] <xclaesse> seb128, I don't understand why we didn't had a torrent of complains, this should have never worked... :/
[09:56] <xclaesse> but it's a race, so maybe it worked by chance, and recent (maybe unrelated) changes makes the timing different and trigger the bug, dunno
[09:58] <seb128> xclaesse, ok, thanks, I will make sure we backport the patch for precise as well
[09:58] <xclaesse> seb128, maybe Guillaume will make point release with the fix
[09:58] <seb128> xclaesse, seems so
[09:58] <seb128> xclaesse, "	prepare <IP_ADDRESS>" commited 3 minutes ago
[09:58] <seb128> xclaesse, in git
[09:58] <seb128> ;-)
 yeah distchecking atm
[09:59] <xclaesse> hehe ok :)
[10:02] <chrisccoulson> hah: http://bazaar.launchpad.net/~mozillateam/ubufox/trunk/revision/298
[10:11] <seb128> hum
[10:11] <seb128> $ sudo chroot /tmp/gcc
[10:11] <seb128> chroot: failed to run command `/bin/bash': No such file or directory
[10:11] <seb128> wth?
[10:15] <seb128> hum, no, my fault
[10:29] <didrocks> ok, doing some exercice while unity is building on quantal for the merger
[11:22] <chrisccoulson> hmmmm, the same person submitted 3 thunderbird crashes to launchpad with apport, despite it being blacklisted :/
[11:22] <chrisccoulson> pitti - do you have any idea why this might happen?
[11:23] <chrisccoulson> (ie, is it possible for somebody to override that without removing /etc/apport/blacklist.d/thunderbird)
[11:23] <chrisccoulson> oh, dang
[11:23] <chrisccoulson> never mind
[11:23] <chrisccoulson> i've just realised why it doesn't work ;)
[11:24] <didrocks> mean /etc/gnome/defaults.list, trying to remove my google-chrome as default browser :)
[11:24] <xclaesse> seb128, bigon is doing telepathy-gabble 0.16.1 package for debian atm ;)
[11:25] <chrisccoulson> didrocks, you should really try a current firefox nightly with gfx.xrender.enabled disabled in about:config, to see if it fixes your launchpad / nvidia issues ;)
[11:25] <didrocks> chrisccoulson: well, I'm on an intel machine right now, but it's kind of late, I got spoiler with the chrome dev tools and having my habit using it :)
[11:27] <chrisccoulson> heh ;)
[11:34] <seb128> xclaesse, nice, I will pick that up later today!
[11:58] <xclaesse> seb128, ah, empathy <IP_ADDRESS> released, better push that one to ubuntu :)
[11:58] <seb128> xclaesse, ok
[12:22] <pitti> chrisccoulson: re (sorry, was at lunch)
[12:22] <pitti> chrisccoulson: hm, which pacakge ships /etc/apport/blacklist.d/thunderbird ?
[12:22] <pitti> chrisccoulson: ah, sorry, I don't have it installed
[12:22] <chrisccoulson> pitti - it's ok, i figured it out right after i asked you :)
[12:22] <pitti> chrisccoulson: ah, why doesn't it work?
[12:22] <chrisccoulson> pitti, a recent upload dropped the "-bin" suffix from the thunderbird binary
[12:22] <chrisccoulson> and i didn't update the blacklist
[12:23] <pitti> ah :)
[12:26] <micahg> gah, I hope that doesn't break any of the apparmor profiles :(
[12:26] <micahg> ah, good, looks like not
[13:03] <seb128> pitti, nice job on the glib testsuit ;-)
[13:03] <pitti> thanks :)
[13:05] <seb128> pitti, I was reading your g+ feed, how come you had to go through those steps for the pandaboard? that's because you didn't want to boot a standard desktop image from the SD?
[13:06] <seb128> pitti, I just had to dd the image on the card here and put it in the board, no other tweak needed
[13:06] <pitti> seb128: yes, indeed; SD is much slower, and they say it's wearing out quickly
[13:06] <pitti> seb128: for precise, I guess?
[13:06] <pitti> seb128: the Quantal kernel is totally busted on my board
[13:06] <seb128> pitti, yeah, I basically followed https://wiki.ubuntu.com/ARM/OmapDesktopInstall
[13:06] <seb128> i.e dumped ubuntu-12.04-preinstalled-desktop-armhf+omap4.img.gz  on the card
[13:07] <pitti> right, 12.04
[13:07] <pitti> anyway, it's quite nice now
[13:07] <pitti> quantal userspace + precise kernel with wifi, ready to ssh in ("ssh panda")
[13:07] <pitti> I really appreciate the builtin wifi
[13:07] <pitti> was nice to debug glib on
[13:07] <seb128> pitti, you still use an SD as disk?
[13:08] <pitti> seb128: only for uboot; the main fs is on USB now
[13:08] <seb128> oh
[13:08] <seb128> is that faster than an sd card?
[13:08] <pitti> maybe, I didn't really compare
[13:08] <pitti> but I have a spare 8 GB USB stick
[13:08] <pitti> while I don't have extra SD cards
[13:08] <pitti> so I can use an old 1 GB SD for booting
[13:09] <seb128> ok, I was curious because you said "SD is much slower, and they say it's wearing out quickly"
[13:09] <seb128> so I though you found a better solution ;-)
[13:09] <seb128> I got mine working nicely but boot is sloooow
[13:10] <pitti> how slow?
[13:10] <pitti> I disabled lightdm (as I only use it for ssh right now), and it's < 10 s
[13:10] <seb128> I do boot a full desktop though, and my 4G sd card is a cheap one (i.e slow)
[13:10] <seb128> over a minute
[13:10] <pitti> with lightdm it's more like 30, yes
[13:10] <seb128> but as said I load a full unity desktop
[13:10] <pitti> oh, so then maybe USB is indeed faster
[13:10] <pitti> but I didn't really measure
[13:11] <pitti> I also turned on unsafe IO in dpkg
[13:11] <seb128> I might play with that another day, I keep your instructions somewhere ;-)
[13:11] <pitti> seb128: once they fix the HDMI bug, it'll be a lot easier with quantal anyway
[13:11] <seb128> right
[13:11] <pitti> by using the desktop live system and ubiquity, instead of the preinstalled
[13:12] <pitti> at least that's what ogra_ told me :)
[13:12] <pitti> I'm still not sure how that magically creates a boot SD when I only have one SD card slot, though
[13:12] <seb128> that's what I used with precise, it was a bit slow but nice otherwise
[13:12] <seb128> hum?
[13:13] <seb128> it doesn't create a new card
[13:13] <ogra_> pitti, it truncates your install media and (ab)uses it like a bootfloppy
[13:13] <seb128> it turns the card where you dumped the image on to an installed system
[13:13] <pitti> ah
[13:13] <pitti> so, it's "do the install" and then "copy over the first partition to a small SD card"
[13:13] <seb128> ogra_, what do you recommend for storage for good performances?
[13:14] <ogra_> pitti, its "do the install" :)
[13:14] <ogra_> nothing manual required
[13:14] <ogra_> seb128, a fast usb key or disk ...
[13:14] <seb128> ogra_, you can put a disk on that?
[13:14] <pitti> ogra_: I am so not going to waste my nice 16 GB SD card that I need for installing just to keep a 75 MB uboot partition and let the rest go to waste :)
[13:14] <ogra_> i found the mid price region to usually get me something around 30MB/s
[13:14] <ogra_> seb128, USB disk, indeed
[13:14] <ogra_> thats how our buildds run
[13:15] <seb128> how
[13:15] <pitti> ogra_: I thought the panda could boot from nothing else than the sd? (uboot, I mean)
[13:15] <ogra_> pitti, 1G will be suffisient
[13:15] <ogra_> seb128, ?
[13:15] <ogra_> how what
[13:15] <pitti> ogra_: oh, you mean the install image will shrink to that? nice!
[13:15] <pitti> ogra_: right now it needs 2, I think
[13:15] <seb128> ogra_, sorry, "can I use only an usb stick", or do I still need an SD for the boot?
[13:15] <pitti> ah, it's a live desktop image indeed, not a preinstall
[13:15] <pitti> so yeah, that'll be nice indeed
[13:15] <ogra_> the install image is a squashfs in a vaft partition, all in all the image takes 600M or even less
[13:16] <ogra_> *vfat
[13:16] <pitti> I can put that 16 GB to my phone then
[13:16] <ogra_> seb128, you still need the SD as "bootfloppy"
[13:16] <seb128> ok
[13:16] <seb128> I get a need a small SD then and a fast usb stick
[13:16] <ogra_> u-boot needs to read kernel and initrd from the first partition of the SD ...
[13:16] <seb128> ogra_, thanks ;-)
[13:16] <ogra_> once in initrd it doesnt matter if you run from SD, USBV or network filesystems
[13:17] <ogra_> well, the SD is usually also your install media, so it should at lest be 1G
[13:17] <ogra_> *least
[13:17]  * didrocks needs to setup that at some point, need to find a SD first :)
[13:17] <ogra_> and if you test *right now* there is bug 1010009
[13:17] <ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009
[13:18] <ogra_> (there are some workarounds noted, not sure they work with all monitors ... )
[13:19] <seb128> ogra_, I did buy a cheap 4G SD card and installed on that this w.e, that works fine but it the card is slooow
[13:19] <seb128> like it takes ages to boot or install packages
[13:20] <seb128> I might just keep that for the base system and add an usb stick for my user dir though
[13:20] <ogra_> yeah, with the live images the install is sloow, but working on USB is a breeze
[13:21] <seb128> ogra_, and we have no excuse now to ignore arm bugs :p
[13:21] <ogra_> hehe :)
[13:21]  * ogra_ would love to have some armadaxp boards send out to the teams ... they can easily cope with an office desktop PC
[13:23] <seb128> ogra_, try to push for arm all the way? ;-)
[13:23] <ogra_> haha, no, actually i just started building an x86 workstation here (the first one since i work for canonical, i only used laptops the last years)
[13:24] <ogra_> but thats because i have to do some x86 work in foundations now and want a fast machine for that
[13:24] <ogra_> i would push for arm all the way if i would see a chance that people would like that ;)
[13:25]  * ogra_ is just in love with power efficiency :)
[14:18] <bcurtiswx> good morning kenvandine, may I PM you?
[14:19] <pitti> seb128: yay, 2.33.3-2 has zero failed tests on armhf
[14:21] <kenvandine> bcurtiswx, sure
[14:24] <seb128> pitti, \o/
[14:27] <mterry> tremolux, heyo!  didrocks volunteered you for a merge review, if you have the time  (https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split/+merge/109209)
[14:28] <didrocks> tremolux: you started to look at it, it sticks :)
[14:28] <tremolux> hmm? I never looked at this??
[14:33] <tremolux> mterry: I don't think I'm going to have a chance to give this a proper review as I've got a small firefight currently, and anyway probs the package maintainers would be way better, no?
[14:33] <mterry> tremolux, they were also busy.  :)  didrocks, maybe you're thinking of barry?
[14:35] <tremolux> mterry: oh, I bet it is barry
[14:35] <tremolux> mterry: looks like impressive work tho  ;)
[14:35] <mterry> :)  any branch with a lot of red looks good
[14:36] <tremolux> mterry: haha! in fact, yes
[14:36] <didrocks> sorry, I meant barry, but I autotyped on the MR ;)
[14:36] <mterry> didrocks, you've got tremolux on the brain
[14:36] <tremolux> didrocks: :D thanks, I was confused about the looking at it part!!
[14:46] <seb128> mterry, hey, do you feel better today?
[14:46] <mterry> seb128, yeah, sleeping all day will work wonders
[14:47] <seb128> mterry, great to read ;-)
[14:48] <kenvandine> mterry, great!
[14:48] <kenvandine> :-D
[15:17] <didrocks> pitti: hey, what's the story about python3 and pygi? (especially when it comes from overrides)
[15:18] <didrocks> pitti: it seems that we don't have overrides files in any python3 path (and so, it's not picked up). Also doing manual tests, I get the overrides working only when putting a file in /usr/lib/python3/dist-packages/gi/overrides/ not in the 3.2 directory
[15:18] <didrocks> do you have any insight?
[15:18] <mhr3> pitti, so, pls explain here to didrocks / sil2100
[15:18] <pitti> didrocks: we are just discussing that with mhr3 in #python :)
[15:18] <mhr3> didrocks, we just talked about it on #python :)
[15:18] <didrocks> ah ok ;)
[15:19] <didrocks> I can join there :)
[15:19] <mhr3> apparently the pkg is built twice
[15:19] <mhr3> once for py2, once for py3
[15:19] <pitti> didrocks: there is nothing magic about them really
[15:19] <pitti> didrocks: put them into $(pyexecdir)/gi/overrides and call configure or setup.py or whatever with the right PYTHON=python3 or python
[15:20] <pitti> just as any other python module
[15:21] <didrocks> pitti: ok, I see them in python3-gi, I'm surprise that the pyexecdir is /usr/lib/python3 and not /usr/lib/python3.2
[15:21] <pitti>     [am_cv_python_pyexecdir=`$PYTHON -c "from distutils import sysconfig; print(sysconfig.get_python_lib(1,0,prefix='$PYTHON_EXEC_PREFIX'))" 2>/dev/null ||
[15:22] <pitti>      echo "${PYTHON_EXEC_PREFIX}/lib/python${PYTHON_VERSION}/site-packages"`])
[15:22] <pitti> is what pygobject does
[15:22] <pitti> some minutes ago I just came up with this from scratch:
[15:22] <pitti> python -c 'import os.path, gi.overrides; print(os.path.dirname(gi.overrides.__file__))'
[15:22] <pitti> or rather ${PYTHON:-python}
[15:22] <pitti> which will also DTRT
[15:23] <didrocks> indeed, that confirms, so the override path always python3, even if we are building with python 3.x, is that general for all python modules? (or rather, all module compatible with 3.x and onward)
[15:25] <didrocks> sil2100: interested in integrated what pygobject does for dee? ^
[15:27] <mhr3> didrocks, so we can revert the rev that adds the python3 dir
[15:27] <didrocks> mhr3: well, we need the override to work for python 2.7 and 3 then, (which isn't the case for now)
[15:27] <didrocks> mhr3: rewrite it for working on both, and then doing 2 builds, right?
[15:29] <mhr3> hmm, seems like exceptions are raised differently in py3?
[15:29] <mhr3> is there universal way?
[15:29] <didrocks> mhr3: I think there is with some __future__ import if we agree to only work in 2.6+
[15:29] <didrocks> mhr3: I can look at it
[15:31] <dobey> mhr3: raised differently?
[15:32] <mhr3> "raise E(msg)" vs "raise E, msg"
[15:32] <dobey> mhr3: "raise Foo, 'message'" no longer works
[15:32] <mhr3> the former is py3
[15:32] <dobey> the former has been in python for a while
[15:32] <mhr3> oh?
[15:33] <mhr3> didrocks, then the patch is trivial
[15:33] <dobey> yep, and "except Foo, e" is gone now, you have to do "Foo as e"
[15:33] <sil2100> didrocks: reading up
[15:33] <didrocks> mhr3: right, with the as
[15:33] <didrocks> and for raise, it's easy
[15:34] <mhr3> didrocks, with the what now?
[15:34] <didrocks> mhr3: let me try it in python2 first
[15:34] <mhr3> works in 2.6 and 2.7
[15:35] <didrocks> mhr3: confirming
[15:35] <didrocks> so that + double build
[15:35] <didrocks> I'm still not sure why the path in python3 and not python3.2, but oh well :)
[15:36] <mhr3> sil2100, i'll revert the python3 commit in my q-fixes branch
[15:37] <sil2100> mhr3: ok
[15:37] <didrocks> mhr3: do you need any autotools-foo help?
[15:37] <didrocks> or will you manage with the call?
[15:37] <didrocks> mhr3: the Dee package will need to build-dep on python2 and 3 then :)
[15:38] <sil2100> didrocks, mhr3: when I wanted to do it, I asked kamstrup for help, but we didn't come to any good solution
[15:38] <sil2100> didrocks: so we're adding python3 as a build-dep in the end?
[15:38] <didrocks> sil2100: yeah, for the import detection path that we saw above ^
[15:38] <didrocks> thanks pitti btw ;)
[15:40] <sil2100> didrocks: can we do it so that it works for both at once? ;)
[15:40] <sil2100> Ah, ok, I see the potential now
[15:40] <mhr3> didrocks, i thought there's nothing necessary, it should detect everything properly
[15:40] <sil2100> Nevermind ;)
[15:40] <pitti> there is no existing best practices for upstream build systems to install stuff for all "installed" python versions at once
[15:41] <pitti> you usally call them for each single $PYTHON you want to support
[15:41] <pitti> and build for
[15:41] <didrocks> mhr3: we will need two builds change, it will be overkill to build dee twice because of that (there is no separate target just to install the override, right?) but I think we can do it that way
[15:41] <didrocks> sil2100: want me to manage that? ^
[15:43] <sil2100> didrocks: hm, so you guys want to build the package twice? I mean, hm, so there will be a python2 and python3 dee version or what?
[15:44] <didrocks> sil2100: not for the override, but the actual build will be done twice
[15:45] <sil2100> didrocks: we'll do that in debian/rules ?
[15:45] <didrocks> yeah
[15:46] <didrocks> mhr3: btw, you can remove the PLATFORM_VERSION in Makefile.am
[15:46] <didrocks> it's not used
[15:46] <pitti> good night everyone!
[15:46] <mhr3> right
[15:46] <sil2100> pitti: good night!
[15:46] <didrocks> have a good night pitti
[15:46] <mhr3> thx pitti, gn
[15:47] <cyphermox> night pitti!
[15:48] <mhr3> sil2100, https://code.launchpad.net/~mhr3/dee/revert-python3-subdir/+merge/112385
[15:49] <mhr3> or didrocks, maybe you want to approve both addition and removal ;P
[15:49] <sil2100> mhr3: ;)
[15:50] <didrocks> mhr3: approved
[15:50] <didrocks> I'm looking at if we can skip having to do configure twice
[15:50] <mhr3> didrocks, no snarky comment? oh come on! :)
[15:51] <didrocks> mhr3: I tried to think of one, but didn't find anything, too late in the day :)
[15:51] <didrocks> now that I know it's your exception, I'll try to make some efforts :)
[15:52] <sil2100> mhr3: the merger failed
[15:52] <sil2100> https://jenkins.qa.ubuntu.com/job/automerge-dee/71/console
[15:53] <mhr3> wow, how come the revert didn't rever that
[15:53] <didrocks> someone didn't remove the ref in configure.ac :)
[15:53]  * didrocks prepares a snarky comment
[15:54] <mhr3> but, but... i did bzr merge -r [addition_revno]..[revno-1]
[15:54] <mhr3> bzr is broken! :P
[15:54] <sil2100> ...;)
[15:54] <didrocks> mhr3: it ignored one file just for you!
[15:54] <sil2100> Didier was waiting for this moment... ;)
[15:55] <sil2100> This very moment ;)
[15:55] <didrocks> I so did \o/
[15:55]  * mhr3 blames bzr for being bribed by didrocks
[15:55] <didrocks> mhr3: my patch to bzr just for you finally worked \o/
[15:56] <didrocks> so, more seriously, there is no other way out than relaunching configure twice :/
[15:56] <mhr3> sil2100, pushed fix
[15:57] <didrocks> anyone has tried double builds with dh7,8,9?
[15:57] <sil2100> mhr3: thanks!
[15:58] <sil2100> didrocks: ouch...
[15:58] <sil2100> didrocks: well, this is a really troublesome thing, that's why I think autotools is hm, not very suited for this :/ I even browsed all the autotools docs yesterday
[15:59] <didrocks> mhr3: so, there will be an issue with the dee branch
[15:59] <didrocks> mhr3: as if I set PYTHON=python3.2, there PYTHON_VERSION is expanded to 3.2
[15:59] <didrocks> to pkgexecdir will be 3.2, not 3
[16:00] <didrocks> mhr3: I think the upstream makefile will have to use pitti's import trunk to know where to install to
[16:00] <mhr3> hmm
[16:00] <didrocks> like ${PYTHON:-python} -c 'import os.path, gi.overrides; print(os.path.dirname(gi.overrides.__file__))'
[16:00] <mhr3> didrocks, or maybe upstream pygi will fix their python.m4 to install it in 3.2 as well
[16:00] <didrocks> mhr3: yeah, maybe, is that a bug or wanted? I didn't get any answer above :)
[16:01] <mhr3> yea, i don't know either
[16:01] <mhr3> should be postpone and ask pitti tommorow?
[16:01] <didrocks> mhr3: I can of course move it in the packaging
[16:01] <didrocks> but I would prefer we do it the right way
[16:01] <didrocks> indeed, let's wait for tomorrow
[16:02] <mhr3> whereever we install, it must be where pygi expects it :)
[16:02] <mhr3> maybe they should just add it to their .pc file
[16:02] <didrocks> mhr3: yeah, at least, with the import, using the PYTHON variable, you will be sure to install it at the right place
[16:02] <mhr3> that would be best imo
[16:04] <didrocks> mhr3: agreed
[16:04] <mhr3> didrocks, i wasn't agreeing with you though, not sure you noticed :)
[16:05] <didrocks> mhr3: well, either the .pc file or the import trick locally ;)
[16:05] <mhr3> well yea, if they won't put it in .pc, then it's the only option
[16:06] <didrocks> mhr3: let's discuss with him tomorrow, we have a clear understanding of different options :)
[16:06] <mhr3> indeed, eod for today anyhow :)
[16:06] <didrocks> even if I have to run configure twice, I can do it in a semi-ugly way for us
[16:06] <didrocks> mhr3: enjoy!
[16:07] <mhr3> didrocks, btw nice monologue on the libunity branch :)
[16:07] <mhr3> you had fun with the bot
[16:07] <didrocks> mhr3: it was so funny, I had to at least make it a full story :)
[16:08] <didrocks> didrocks, "entertainement provider"
[16:08] <didrocks> for mhr3's pleasure :)
[16:08] <mhr3> heh, thx then
[16:08] <didrocks> (even if it wasn't a monolog, the merger bot was responding to me… ok not the way I wanted to… ;))
[16:12] <sil2100> ;)
[16:20] <seb128> didrocks, kenvandine, Laney, Sweetshark, bryceh, chrisccoulson, kenvandine, TheMuso, cyphermox, mterry, tkamppeter: hey, did anyone landed work which is work mentioning in the alpha2 notes?
[16:20] <didrocks> not really for me
[16:20] <seb128> things in quantal-proposed don't count since they are not in a2
[16:20] <mterry> no
[16:22] <seb128> you guys might be awesome but we will look like a boring team for a2 it seems ;-)
[16:22] <seb128> kenvandine, chrisccoulson, cyphermox: nothing to save us? ;-)
[16:22] <seb128> I guess we updated glib, gtk and a part of GNOME
[16:23] <cyphermox> well, I ported software-properties to python 3 but that's not landed, waiting for review ;)
[16:23] <cyphermox> if someone wants to have fun reviewing stuff ...
[16:23] <seb128> hehe
[16:23] <cyphermox> just say we did awesome supersecret stuff
[16:23] <cyphermox> but then we'll have to deliver for the next milestone ;)
[16:24] <seb128> cyphermox, you can join the line behind mterry
[16:24] <seb128> cyphermox, the line of people who did nice work and are waiting on review ;-)
[16:24] <bryceh> seb128, mesa 8.0.3 and a new -ati driver.  dunno if that counts as worth mentioning
[16:24] <cyphermox> seb128: is there a line for people who did potentially crappy work, but wiating for review? ;)
[16:24] <seb128> bryceh, I don't think it's significant enough for release notes, we will put xserver 1.12 for the next iteration
[16:25] <mterry> cyphermox, kenvandine is patch pilot!  :)
[16:25] <seb128> cyphermox, lol
[16:25] <cyphermox> weeee
[16:25] <bryceh> seb128, ok
[16:25] <mterry> cyphermox, but he's doing my branch right now, I hope
[16:25] <seb128> yeah, show the love for kenvandine
[16:25] <seb128> he usually complains that he has nothing to pilot because he's always on duty the same day as didrocks and Didier rocks the sponsoring before he wakes up
[16:26] <seb128> ;-)
[16:26] <didrocks> heh, good that this can keep him busy this time :)
[16:56] <seb128> dobey, hey, any news about the SRU for ubuntu-sso-client?
[17:02]  * didrocks waves good evening
[17:05] <tkamppeter> seb128, nothing new for alpha2 from my side.
[17:11] <dobey> seb128: getting everything in quantal first
[17:11] <seb128> dobey, do you have any eta for it?
[17:12] <dobey> seb128: i can probably do it tomorrow
[17:12] <seb128> dobey, great, thanks
[22:36] <Laney> gsd sure has a lot of patches
[22:40] <robert_ancell> Laney, scary huh?
[22:40] <robert_ancell> bcurtiswx, are you still working on the empathy update?
[22:41] <bcurtiswx> Hey robert_ancell , I got married last weekend so sorry for the delay. I will get merge requests updated for the newest released empathy's tomorrow
[22:41] <robert_ancell> bcurtiswx, np, congrats!
[22:41] <bcurtiswx> robert_ancell: Thx :)
[22:44] <robert_ancell> jbicha, hey, have you seen http://people.canonical.com/~platform/desktop/gnome.html?
[22:46] <robert_ancell> jbicha, also, it now looks in debian svn so I will see if you update something there
[22:57] <robert_ancell> desrt, can you review gvfs bugs? https://bugzilla.gnome.org/show_bug.cgi?id=676693
[22:57] <ubot2> Gnome bug 676693 in udisks2 volume monitor "[PATCH] Fix error when compiling with -Werror=format-security" [Normal,Unconfirmed]
[23:00] <jbicha> wow, that script takes 66 minutes to run?!
[23:00] <robert_ancell> jbicha, yeah, it needs some optimisation
[23:01] <jbicha> even before, the version script was a pain to update if I wanted to test-run it before uploading
[23:02] <robert_ancell> jbicha, patches welcome :)
[23:03] <jbicha> and what do you mean by svn? as an example, evince 3.4.0-3 was started in Debian svn yesterday but it's not on the chart
[23:04] <robert_ancell> hmm, it must have broken again.  libzapojit was working yesterday, now it just shows "None"
[23:04] <robert_ancell> ok, I think I fixed it, just have to wait 1.5hours to check
[23:05] <robert_ancell> jbicha, seb128 wants to split the version checked from the renderer, then it should be easier to test
[23:05] <robert_ancell> checker
[23:08] <robert_ancell> ok, time to try new gtk...
[23:26] <robert_ancell> RAOF, so did you work out what we need to do to get colord moving?
[23:48] <RAOF> robert_ancell: Getting that MIR processed would be it; I'm not sure why the launchpad thinks the source is in main; gusb hasn't had any main B-Ds until colord.