[02:02] <psusi> bug #1198846 complains that if you have both the dvd and usb installation media present, the system mounts the usb instead of the dvd when you ask the bios to boot the dvd.  my first instinct was to close this as not a bug but it has "OEM Priority Project" tasks.  what exactly does that mean?  someone is paying Canonical to do something about this?  so should I leave it alone then?
[02:05] <ScottK> psusi: All it means, AIUI, is that it affects something Canonical OEM services is doing.  Hard to say exactly what.
[02:06] <ScottK> I don't think you should triage the Ubuntu bug task any differently than you normally would.
[02:07] <slangasek> agreed; if it needs to get escalated within Canonical to fix it, that's not something you should need to worry about
[02:07] <slangasek> and in the first instance, if the community devs think it's a wontfix issue, you shouldn't hesitate to mark it as such
[02:13] <psusi> cool
[02:47] <Noskcaj> roaksoax, kirkland: ping (
[03:34] <Noskcaj> Logan_, about bug 1185765 ...
[03:36] <roaksoax> Noskcaj: pong
[03:37] <Noskcaj> roaksoax, a few thing: 1. the description of testdrive is very outdated on the lp page. 2. It seems installing testdrive from source doesn't work. 3. Find some time for a testdrive hackfest, please.
[03:37] <Noskcaj> mostly number 1
[03:39] <smartboyhw> roaksoax, and plz, do give us a wiki page or something to teach people how to hack on Testdrive.
[03:39] <Noskcaj> +1 to that.
[03:39] <Noskcaj> that's pretty much my goal for a hackfest day
[03:47] <Noskcaj> he ran away again, didn't he.
[03:47] <smartboyhw> Noskcaj, where the hell is multibootusb in Ubuntu/
[03:47] <smartboyhw> ?
[03:48] <Noskcaj> "apt-cache search multibootusb" gives the result: multibootusb - Multiple live linux on USB.
[03:49] <smartboyhw> Noskcaj, hah?
[03:49] <smartboyhw> I don't get it here
[03:49] <smartboyhw> * can't
[03:50] <Noskcaj> dam, it's just a broken repo on my PC
[03:50] <smartboyhw> Noskcaj, can you please confirm if you enabled https://launchpad.net/~upubuntu-com/+archive/ppa ?
[03:50] <smartboyhw> Noskcaj, so, it doesn't exist, please package it
[03:50] <smartboyhw> :P
[03:51] <Noskcaj> yeah, that's what it was. i'm working on it now
[03:52] <smartboyhw> Noskcaj, great:)
[03:52] <smartboyhw> Shouldn't be very difficult I hope:)
[03:58] <Noskcaj> what do i do is a program i'm trying to package already has a .deb?
[04:14] <Noskcaj> roaksoax, one other thing. the testdrive .dsc file isn
[04:14] <smartboyhw> Noskcaj, well, you still have to package it even if it has a deb
[04:14] <Noskcaj> 't lintian clean
[04:14] <smartboyhw> Noskcaj, lintian clean is rather difficult you know:P
[04:15] <smartboyhw> We try to make it lintian clean
[04:15] <Noskcaj> all i know is an error appeared
[04:15] <smartboyhw> Noskcaj, what's the lintian message?
[04:15] <Noskcaj> W: testdrive source: out-of-date-standards-version 3.9.3 (current is 3.9.4)
[04:15] <Noskcaj> looking at the lintian website, it looks like a fairly easy fix
[04:15] <smartboyhw> Noskcaj, ah, simple
[04:16] <smartboyhw> Noskcaj, wait till the next feature upload will be better
[04:16] <Noskcaj> ok
[04:26] <roaksoax> Noskcaj: lintian clean doesnt mean theres no lintisn warnings or stuff
[04:27] <Noskcaj> ok, i'm new to this
[04:27] <roaksoax> Noskcaj: no worries. you will gain more experience with prsctice.
[04:27] <roaksoax> yhe error of testdrive 3.20 is because of pygobject
[04:28] <roaksoax> idk whether its upstream or testdrive issue
[04:28] <roaksoax> but it hsppenend sfter tje upgrade of libraries
[04:30] <roaksoax> Noskcaj: could you please file bugs thatd easier for me to track
[04:30] <Noskcaj> roaksoax, ok.
[04:33] <smartboyhw> Noskcaj, I'm thinking of the multibootusb package, how will you filll in the copyright file?
[04:33] <smartboyhw> Looks like it's very difficult:P
[04:33] <Noskcaj> smartboyhw, i've pretty much given up on that one, since it's my first package
[04:34] <Noskcaj> i've contacted the guy who makes it and am awaiting reply
[04:34] <smartboyhw> Noskcaj, copyrights are VERY important (as I learnt in Kubuntu packaging)
[04:34] <smartboyhw> I got rejects solely because of that file
[06:17] <Noskcaj> roaksoax, bug 1199235
[07:26] <dholbach> good morning
[08:19] <xnox> @pilot in
[08:24] <m4n1sh> ev: ping. can you have a look at the mail I sent you a few days back related to LP 1197974
[08:25] <m4n1sh> whenever you are free
[08:29] <ev> m4n1sh: yup, will do. For what it's worth, it's a harmless error
[08:29] <ev> it just means that the code tried to reflect the UI state in the configuration file, but the user hadn't pressed the "unlock" button yet
[08:29] <m4n1sh> ev: well, i don't know much about that component, so referred it to you. reported by jbicha
[08:30] <ev> sure thing
[10:46] <ev> is there a trick to getting qtcreator to set LD_* correctly? I'm trying to build and run ubuntu-system-settings locally, but it fails with 'libSystemSettings.so.1: cannot open shared object file: No such file or directory'
[10:47] <Laney> I've just been building the package :(
[10:58] <ev> seb128: ^ any idea?
[11:03] <seb128> ev, Laney: no idea, I don't run it from qtcreator either
[11:03] <ev> seb128: thanks all the same
[11:03] <seb128> but mardy_ can maybe help there...
[11:04] <mardy_> ev: I don't use qtcreator either, but I know you can change the environment variables used when running your app
[11:05] <seb128> mardy, hey, welcome back ;-)
[11:05] <mardy> seb128: thanks :-)
[11:05] <seb128> mardy, I'm looking at a system setting translation issue ... do you have a preference on translating displayName in the backend or in the UI?
[11:05] <ev> thanks
[11:06] <seb128> mardy, I'm not sure if I should add the tr() call to the item-model.cpp code or in the UI
[11:09] <mardy> seb128: I'd probably do that in the UI, but IMHO both are fine
[11:20] <seb128> mardy, ok, I found how to do it in the UI (I was just missing the gettext domain), merge request coming in a bit
[11:20] <seb128> mardy, https://code.launchpad.net/~seb128/ubuntu-system-settings/storage-bar-border/+merge/173672 ... did you mean to change the mr status as well?
[11:21] <seb128> mardy, I've no strong opinion on the anchors, I just tend to try to go for "less lines of code"
[11:21] <seb128> ;-)
[11:21] <mardy> seb128: no, it's fine, I just wanted to wait for your reply. I've approved it now :-)
[11:22] <seb128> mardy, ok ;-)
[11:22] <seb128> mardy, is there any difference in behaviour/performance between both ways?
[11:22] <seb128> mardy, or is it just that you find it easier to read when declared with left/right/...
[11:22] <seb128> mardy, oh, and thanks for the review ;-)
[11:47] <cjwatson> tjaalton: Could you please look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707064 ?  If you need help I can try to come up with something
[11:54] <tjaalton> cjwatson: yeah I should sync with upstream first, fedora has done the transition earlier this year iirc
[11:58] <tjaalton> well, they just patched upstream
[12:00] <mlankhorst> sforshee: did you try the macbook yet on 3.11 pre rc?
[12:03] <valavanisalex> Hi All, can anyone point me to example source packages that use the new elegant "dh" debhelper syntax to build multiple binaries using different configuration options.  I looked at the vim and mpb packages but both of these use the old semi-manual dh_* syntax in the rules file.  In fact, is this even possible using dh?
[12:11] <zyga> cjwatson: ping
[12:11] <tjaalton> cjwatson: ok I have the source sorted out, now need to migrate the packaging
[12:11] <zyga> cjwatson: I'm looking for some advice, what it the current best way to test dbus services? spawn a separate bus and test on that?
[12:12] <zyga> cjwatson: mock the hell out of dbus? (feels wrong though)
[12:12] <zyga> cjwatson: or something else?
[12:12] <zyga> cjwatson: the service is written in python3
[12:12] <cjwatson> zyga: pitti has a dbusmock library or something along those lines
[12:12] <cjwatson> tjaalton: cool, thanks
[12:12] <zyga> cjwatson: oh, I'll have a look
[12:12] <zyga> cjwatson: thanks!
[12:13] <cjwatson> tjaalton: http://wiki.debian.org/Apache/PackagingFor24 is fairly easy to follow
[12:13] <tjaalton> k thanks
[12:14] <cjwatson> valavanisalex: you can do anything with dh; it may just require lots of overrides.  openssh builds two variants of itself for instance
[12:14] <zyga> cjwatson: that looks awesome, thanks!
[12:14] <cjwatson> valavanisalex: or grub2 but that is Complex
[12:15] <cjwatson> (and actually grub2 is a slightly strange mix of styles so perhaps not the best example)
[12:16] <cjwatson> valavanisalex: the main important thing to realise is that you can override dh_auto_* to run each of your relevant build passes
[12:16] <cjwatson> valavanisalex: for instance Python packages (*searches for random example* e.g. germinate) tend to run a build pass for each version of Python they're building for
[12:17] <cjwatson> zyga: thank pitti, but yes :)
[12:17] <cjwatson> one of these days maybe I should convert ubiquity to use that
[12:20] <xnox> valavanisalex: cjwatson: with debhelper 9, one can define "build:" target and just do all the building there as compex, as needed. dh, will notice and run those commands instead of dh_auto_* stuff.
[12:20] <xnox> cjwatson: for ubiquity build, i'd love to somehow multiplex and build included packages in-parallel, but with sane/sorted build-log.
[12:29] <cjwatson> xnox,valavanisalex: You can do that.  It can have some surprising effects, and I've generally found it better to use overrides.
[12:29] <cjwatson> xnox: Yes
[12:35] <tjaalton> cjwatson: is apache 2.4 in saucy-proposed yet?
[12:36] <cjwatson> tjaalton: Yes
[12:36] <cjwatson> tjaalton: But better to do the transition in unstable and let it autosync, where possible
[12:36] <tjaalton> sure
[12:36] <cjwatson> tjaalton: (I guess you'll need a manual sync in this case)
[12:36] <tjaalton> I'll test the builds against sid anyway
[12:37] <tjaalton> but need someone to sponsor it
[12:37] <cjwatson> I can do that
[12:37] <sforshee> mlankhorst: I haven't tried 3.11 yet on any macbooks
[12:38] <jdstrand> gema_: hi! should I use the qa-daily-testing tag on a bug for smoke testing failures? ie, I want bug #1199351 to show up for the failures for http://reports.qa.ubuntu.com/smokeng/saucy/image/2900/ and http://reports.qa.ubuntu.com/smokeng/saucy/image/2899/
[12:39] <gema_> jdstrand: it's not a tag in the lp sense, if you want them to show in the dashboard, the bug number needs to be added to jenkins
[12:39] <gema_> jdstrand: we can do that, or you can do it if you have access to the lab
[12:39] <jdstrand> gema_: how do I do that?
[12:39] <jdstrand> I think I do. I'd like to try, so I can do it in the future
[12:40] <gema_> ack
[12:40] <gema_> so connect to the vpn
[12:40] <gema_> I will tell you how to find the right job
[12:40]  * jdstrand is connected
[12:40] <gema_> ok
[12:40] <gema_> so this is the job that you want tagged: https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-security/15/?
[12:41] <gema_> all we need to find it's equivalent in the internal jenkins
[12:41] <jdstrand> yes
[12:46] <mlankhorst> sforshee: did anything land in 3.11 related to macbook though? like the pci crap perhaps
[12:48] <sforshee> mlankhorst: not that I'm aware of, but I haven't been monitoring it closely
[12:48] <mlankhorst> hm then again nfs seems to be dying again now too, maybe it is related to that..
[13:00] <tjaalton> cjwatson: hm, seems to otherwise work, but somehow dh_strip doesn't strip the module as it used to
[13:01] <stgraber> barry: system-image meeting in #ubuntu-meeting
[13:03] <tjaalton> cjwatson: oh I know, guess dh_apache2 copies an unstripped version there, this doesn't use dh yet
[13:04] <tjaalton> so I just added dh_apache2 after dh_install
[13:06] <ev> mpt: any idea who I need to talk to about getting an icon made up for "diagnostics" in ubuntu-system-settings, or are you already on it?
[13:13] <seb128> ev: talk to tiheum from design about icons
[13:14] <ev> seb128: what good fortune. I'm facing him.
[13:14] <ev> will do, thanks
[13:14] <seb128> ev: yw ;-)
[13:15] <blitzkrieg3> you mean
[13:15] <seb128> ev: let me forward you an email with the icons he sent us
[13:15] <ev> thank you
[13:15] <seb128> ev: there is the one you want in there
[13:19] <seb128> ev: email sent
[13:21] <ev> perfect! thanks seb128!
[13:22] <seb128> ev: yw!
[13:24] <Laney> seb128: what about the colour editing thingy you told me to do?
[13:24] <Laney> or did that get fixed?
[13:25] <seb128> colour editing... me tries to remember
[13:25] <seb128> Laney, oh, I included that in the email
[13:25] <Laney> aha
[13:25] <seb128> it's cccccc -> 808080 in the svg
[13:25] <Laney> thought that extra detail might have been left out
[13:25] <Laney> nm
[13:26] <tjaalton> cjwatson: ok it's fixed
[13:27] <seb128> Laney, thanks for checking ;-)
[13:28] <cjwatson> tjaalton: Lovely, thanks
[13:30] <tjaalton> cjwatson: pushed the source to http://kernel.ubuntu.com/~tjaalton/tmp/
[13:36] <mpt> ev, wait, you have the stethoscope icon?
[13:36] <ev> I have a heartbeat monitor icon
[13:37] <ev> you can see it if you come over here :)
[13:37] <mpt> oh cool
[13:37] <mpt> But that involves walking, like, six steps
[13:37] <ogra_> use a hangout !
[13:37] <ev> hahaha
[13:38] <mpt> Five minutes to set up the hangout, five more minutes to figure out the screen sharing feature
[13:38] <ogra_> but you dont have to walk
[13:38] <cjwatson> tjaalton: your .dsc has a different .orig.tar.gz size from the one in Debian unstable - I guess I'm safe to ignore that?
[13:38] <tjaalton> cjwatson: oh.. yes please do. I'll fix mine
[13:38] <cjwatson> tjaalton: Oh, it's different in unstable vs. saucy
[13:39] <tjaalton> duh
[13:39] <cjwatson> tjaalton: That sucks, it'll have to be a fakesync
[13:39] <tjaalton> can't remember why it was originally
[13:39] <cjwatson> tjaalton: They're identical file contents, but packed independently from different top-level directory names
[13:40] <cjwatson> Ah well
[13:40] <cjwatson> Get it right next upstream release ;-)
[13:40] <tjaalton> yeah, I'll poke upstream (@redhat) to actually release a new version and not just patch the package all the time
[13:49] <smartboyhw> SRU team members: Can you try to review Bug 1189083 and Bug 1189085's SRU patch into Raring, I want to test it today or tomorrow as I'm leaving tomorrow afternoon (UTC time).
[13:49] <smartboyhw> And upload, ofc:P
[14:09] <smartboyhw> Nobody help? ^
[14:39] <seb128> barry, hey
[14:39] <barry> seb128: hi
[14:39] <seb128> barry, is that known that your python-configglue updates broke ubuntuone-syncdaemon on saucy?
[14:40] <barry> seb128: no, but add it to the list :(
[14:40] <barry> it also broke software-center and virtualenv
[14:40] <seb128> barry, can you try running /usr/lib/ubuntuone-client/ubuntuone-syncdaemon
[14:40] <seb128> ?
[14:40] <barry> not python-configglue directly, but its new dependence on python-configparser
[14:40] <seb128> barry, seems like we need autopkgtests in python-configglue to make sure it doesn't break all our softwares when updated ;-)
[14:40] <barry> the latter which seems to break a lot of stuff
[14:42] <barry> seb128: yeah, i need to untangle all of that.  i may have to talk to pindonga about dropping that dep so we can kill -configparser out of the archive
[14:42] <cjwatson> seb128: you need tests in the packages that depend on python-configglue, you mean :)
[14:42] <seb128> cjwatson, right ;-)
[14:42] <barry> configglue is fine, configparser is killing us
[14:43] <seb128> dobey, ^ would be nice to have in s-c and u1-syncdaemon
[14:43] <barry> (well, fine module its dependence on the latter ;)
[14:43] <dobey> seb128: software-center is fixed already
[14:43] <barry> *modulo
[14:43] <seb128> barry, well, downgrading configglue makes u1 work again
[14:43] <seb128> but yeah
[14:43] <barry> yeah
[14:43] <dobey> well, i fixed the crash that was caused by configparser
[14:44] <barry> i don't have time to look right now, but i suspect configglue doesn't *really* need configparser (iow, it can be written against ConfigParser for py2)
[14:44] <dobey> almost certainly
[14:44] <barry> i'm trying to decide whether it's better/possible to fix configparser or kill it off
[14:45] <barry> (or at least relegate it to universe)
[14:45] <dobey> kill kill kill
[14:45] <barry> anyway, it's third on my todo list for today :)
[14:46] <dobey> "backports" of python3 modules onto python2 are evil, and tend to break things in weird ways
[14:46] <dobey> particularly things that have to work on both versions and do things like try: import configparser except ImportError: import ConfigParser
[14:46] <barry> seb128: is there a bug for the syncdaemon breakage?  if not, please file one, i need ammo :)
[14:47] <barry> dobey: right.  it would be much better to be named something that doesn't overlap with a py3 stdlib package name
[14:48] <seb128> barry, dobey: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/1198480
[14:48] <dobey> barry: the problem is people write code for py3, and then someone says "i must run this on py2" and so they just take the py3 core module and make it "work" on py2, and ship it as is
[14:49] <barry> dobey: that is a problem
[14:50] <dobey> it wouldn't be so bad if they were all namespaced into a "py3backports" package or something
[14:50] <dobey> at least then they wouldn't break things that aren't intentionally using them
[14:52] <barry> cjwatson: btw, today's updates broke x.org for me too :/
[14:53] <barry> well, at least the greeter doesn't start
[14:53] <smartboyhw> Hmm, sounds like nobody noticed my request or something:(
[14:54] <wookey> libjpeg-dev in raring is not MA:same (and is arch:all so things which build-dep on it end up getting the wrong-arch version of libjpeg-turbo-dev installed
[14:55]  * barry thanks his disk snapshots
[14:56] <cjwatson> barry: all I know about it is what I saw in proposed-migration, which isn't very relevant for this :)
[14:56] <barry> cjwatson: yeah
[14:56] <cjwatson> wookey: raring is what it is with regard to multiarch - I suggest getting it fixed in saucy :)
[14:57] <wookey> cjwatson: yeah. I know - I just discoered it there helping someone build his stuff
[14:57] <wookey> and was checking that we agree this is wrong - I know there is a load of complexity around the 'two different libjpegs' fight
[14:58] <sil2100> Wellark: hi!
[14:58] <cjwatson> I don't agree it's "wrong" in that we haven't yet said it's a bug for -dev packages not to be multiarch, but it sounds as though it could be improved
[14:59] <cjwatson> I'm not totally sure of the intended semantics of <Architecture: all> Depends: <Multi-Arch: same>
[14:59] <sil2100> Wellark: I saw you are working on unity-action-api - how does the status look like currently?
[14:59] <wookey> cjwatson: it's always wrong SFAIK
[14:59] <cjwatson> slangasek probably knows
[15:00] <wookey> which is why we fixed it in libdb-dev
[15:00] <cjwatson> wookey: arguably; but in this case it seems kind of reasonable
[15:00] <cjwatson> I mean, it's wrong by assertion rather than by obviousness, I feel :)
[15:00] <wookey> although we have a much bigger problem with that sort of things outside C-library world
[15:00] <wookey> (e.g perl modules)
[15:00] <cjwatson> that said, the current setup means that you can't do B-D: libjpeg-dev, libjpeg-dev:native and have it work
[15:00] <cjwatson> so that rather suggests that libjpeg-dev Arch: any M-A: same would be more correct
[15:01] <Wellark> sil2100: timp is working on integrating it directly to the UITK
[15:01] <slangasek> the defined semantics are that the dep of an Arch: all package on an M-A: same package can only be satisfied by the package of the primary arch; if you need something more complex the package needs to be changed to no longer be Arch: all
[15:01] <Wellark> sil2100: it should be ready to be used next week
[15:01] <sil2100> Wellark: ok, so no daily-releasing for now until that's done?
[15:03] <sil2100> Wellark: or will the package be removed completely and integrated into UITK somehow?
[15:04] <Wellark> sil2100: the package will be in main. If you are using UITK then you will have it already set up if you use MainView and Page
[15:04] <Wellark> sil2100: but if you develop an application that does not use UITK then you can use the direct QML API
[15:05] <sil2100> Wellark: ok, all clear - then I'll ping you back again next week, thanks!
[15:09] <Wellark> sil2100: np :)
[15:09] <xnox> wookey: uploaded libjpeg8-empty to fix that.
[15:10] <xnox> @pilot out
[15:10]  * xnox => lunch
[15:18] <wookey> xnox: chers very much![D[D[D[D[D[D[D[D[D[D[D[D[De
[15:18] <wookey> why would libtwin be in raring and previous 4 releases, but not saucy?
[15:19] <Sarvatt> its in saucy..?
[15:20] <Sarvatt> https://launchpad.net/ubuntu/+source/libtwin
[15:22] <wookey> hmm. but it doesn;t appear in http://packages.ubuntu.com/search?suite=saucy&section=all&arch=any&keywords=libtwin-dev&searchon=names
[15:22] <wookey> that's what confused me
[15:22] <Sarvatt> doesnt look like anything on saucy is on there
[15:29] <cjwatson> wookey: packages.u.c is out of date I think; don't trust it
[15:34] <cjwatson> tjaalton: uploaded, sorry for the delay
[15:35] <cjwatson> tjaalton: can you deal with the fakesync into Ubuntu or want me to?  (syncpackage -F deals with that easily these days)
[15:40] <tjaalton> cjwatson: woot, thanks.. i can handle that part
[15:48] <rbasak> Should I normally have to explicitly specify -sa to debuild when preparing a merge? I just got a rejection because I didn't upload the orig tarball. I can do it again with -sa, but just want to make sure that it's expected and I haven't done something else wrong.
[15:48] <cjwatson> rbasak: Yes
[15:49] <rbasak> OK, thanks!
[15:58] <tumbleweed> err, if you use -v, doesn't wit work out if it needs -sa or not?
[15:58] <xnox> rbasak: also correct -v is nice as well.
[15:58] <xnox> tumbleweed: not really, it only incudes tarball for -1 -0ubuntu1, but not like for -3ubuntu1
[16:16] <valavanisalex> cjwatson: Sorry for the slow reply; thanks very much for the help.  I'll take a look at those packages for inspiration.
[16:29] <seb128> jibel, hey, I just got an email about "Jenkins Failure - saucy-adt-libproxy 42" pointing to https://jenkins.qa.ubuntu.com/job/saucy-adt-libproxy/42/?
[16:29] <seb128> jibel, which has "no test"
[16:29] <seb128> jibel, do you know what's going on there?
[16:30] <jibel> seb128, mkdir: cannot create directory `/dev/shm/adt': Permission denied, it is a problem on the testing node
[16:30] <jibel> seb128, I'll look into this
[16:30] <seb128> jibel, where do you see that?
[16:30] <seb128> jibel, thanks
[16:30] <seb128> jibel, just got a similar one for poppler
[16:30] <jibel> seb128, https://jenkins.qa.ubuntu.com/job/saucy-adt-libproxy/42/ARCH=amd64,label=adt/console
[16:30] <Laney> amd64 -> console output
[16:31] <seb128> thanks
[16:31] <seb128> I was just looking at the "no test" empty page :p
[16:31] <seb128> I didn't think about clicking on the side
[16:31] <seb128> the jenkins UI is not the most obvious thing
[16:32] <jibel> there is no better UI than jenkins ;)
[16:33] <Laney> It's like mpt himself designed it
[16:35] <jibel> seb128, fixed, now I'm wondering how it could lose this mount point
[16:35] <jibel> seb128, I'll re-run poppler and libproxy
[16:35] <seb128> jibel, 'ci
[16:38] <Laney> jibel: glib2.0 too please
[16:39] <jibel> Laney, done too, I re-triggered all the tests that failed
[16:39] <Laney> ah OK, it didn't sound like you had a complete list
[16:39] <Laney> thanks
[16:42] <mpt> seb128, jibel: You may have realized this, but it's easy for "the jenkins UI is not the most obvious thing" and "there is no better UI than jenkins" to be true at the same time. :-)
[16:44] <seb128> mpt, is it?
[16:45] <infinity> If you qualify the second statement with "for the task at hand", perhaps.
[16:45] <mpt> Sure, if the state of the art is terrible
[16:45] <infinity> I could probably vomit a better UI than Jenkins.
[16:56] <slangasek> infinity: but if you do, you should seek medical attention
[17:44] <cjwatson> mdeslaur: Could you please either merge php5 or tell me I can?  It's important for the Apache 2.4 transition in progress.
[17:45] <infinity> cjwatson: Robie was going to look at php5.
[17:45] <infinity> rbasak: ^
[18:33] <unixabg> Greetings, is there a way to stack on a read only persistent layer when booting live cd? Say like casper-ro?
[18:33] <unixabg> I ask since I would like to deploy live image with some additions and make them act more like a firmware install.
[18:34] <sarnold> unixabg: perhaps overlayfs can get you there
[18:36] <unixabg> sarnold: First thank you for the response, can I do this with a defalut official ubuntu live iso?
[18:37] <unixabg> I am trying to avoid remastering so I can stay with current releases.
[18:37] <sarnold> unixabg: if you have a live image booted, check /proc/filesystems for overlayfs
[18:39] <unixabg> sarnold: booting one now, one moment..
[18:43] <unixabg> sarnold: ok booted, and cat /proc/filesystems lists :   nodev    overlayfs
[18:46] <dobey> barry: the big problem seems to just be that configglue now returns unicode() for lots of things on py2 where it used to return byte strings as str()
[18:46] <dobey> barry: at least, as far as configglue/configparser relates to breaking ubuntuone-syncdaemon
[18:47] <unixabg> sarnold: I am not sure how to utilize to achieve ro persistence with default iso. I can configure entries in grub if this helps.
[18:48] <barry> dobey: let me see if i can get pindonga in on the conversation
[18:50] <barry> pindonga: hi
[18:50] <pindonga> hi
 barry: the big problem seems to just be that configglue now returns
[18:50] <barry>         unicode() for lots of things on py2 where it used to return byte
[18:50] <barry>         strings as str()
 barry: at least, as far as configglue/configparser relates to breaking
[18:50] <barry>         ubuntuone-syncdaemon
[18:50] <barry> blah, ugly paste
[18:50] <dobey> right. it's probably the result of configglue returning unicode() instead of bytes
[18:51] <dobey> err
[18:51] <barry> pindonga: so, python-configparser broke software center, is breaking syncdaemon and virtualenv too
[18:51] <dobey> configparser returning them, that is
[18:51] <pindonga> barry, well, python-configparser is a backport of the py3 configparser, yes?
[18:51] <pindonga> which is backwards incompatible with py2's ConfigParser
[18:51] <dobey> which of course breaks everything
[18:52] <dobey> pindonga: it's backwards-incompatibile with the fact that python2 doesn't use unicode by default
[18:52] <dobey> at least, that's why it is breaking ubuntuione-syncdaemon
[18:52] <pindonga> so, what's the issue here? why is python-configparser needed?
[18:52] <dobey> pindonga: configglue is depending on it, and thus pulling it in
[18:52] <barry> pindonga: it's a dependency on -configglue now afaict
[18:52] <pindonga> ie, if we're not packaging the latest configglue it should be no problem yes?
[18:53] <pindonga> right, why do we need the latest configglue then?
[18:53] <barry> pindonga: we're packaging it now :)
[18:53] <dobey> 1.1.0 is in sauncy
[18:53] <pindonga> 1.0.3 should work fine with py2
[18:53] <dobey> err saucy
[18:53] <pindonga> 1.1.0 and 1.1.1 are py3 compat
[18:53] <barry> pindonga: for py3 in saucy
[18:53] <dobey> yes, but it breaks compat with py2
[18:54] <dobey> because things that were str() in python2 are now unicode()
[18:54] <pindonga> ok, what do you suggest?
[18:54] <barry> pindonga: how difficult would it be for py2 configglue to just use stdlib ConfigParser instead of python-configparser?
[18:54] <pindonga> why don't we ship 1.0.3 ?
[18:54] <pindonga> barry, the main problem is that it won't work with py3
[18:54] <dobey> pindonga: try: except: like everyone else that supports both versions?
[18:55] <pindonga> well, if we want to support both versions, maybe ;-)
[18:55] <barry> pindonga: sure, but configglue is now py2 and py3.  so you could use `from ConfigParser import ConfigParser` for py2 and wrap that in a try/except
[18:55] <pindonga> I can give it a try
[18:55] <barry> with the except being `from configparser import ConfigParser`
[18:55] <dobey> pindonga: well, "want" is a strong word. we have to support both versions :)
[18:55] <pindonga> I can't guarantee it'll work, but I'll let you know if I manage to
[18:56] <dobey> or we have to ship two different versions of configglue
[18:56] <pindonga> there are many changes between py2 and py3 in ConfigParser
[18:56] <pindonga> too many
[18:56] <barry> pindonga: do the py2 import in the try
[18:56] <pindonga> barry, the main problem is the api changed
[18:56] <pindonga> so it's not just like changing the import
[18:56] <barry> pindonga: do you use the new api?
[18:56] <dobey> pindonga: are you actually using the new API?
[18:56] <pindonga> afaik there is only one api
[18:57] <pindonga> as said... will give it a go and see what happens
[18:57] <pindonga> my initial attempts were'nt successfull
[18:57] <pindonga> hence I opted for the backported configparser
[18:57] <dobey> barry: do we even ship any applications that use configglue on python3?
[18:58] <barry> pindonga: thanks for giving it a shot.  i can help out more later today
[18:58] <dobey> i don't think we do
[18:58] <barry> dobey: not yet, but it's a dep for porting other things we need to get off of py2
[18:58] <barry> dobey: e.g., yeah you guessed it: ubuntuone-client
[18:59] <dobey> ubuntuone-client is the only thing that uses configglue at all, really
[18:59] <dobey> unless you plan to port django as well :)
[18:59] <barry> really, i think python-configparser is quite ill-advised and i am going to contact upstream about "the problem"
[19:00] <barry> doesn't django already support py3?  maybe not packaged yet, but that's a SMoE
[19:00] <barry> :)
[19:01] <dobey> i'm just saying, it's ubuntuone and a module for django to use configglue in a django app. those are the only things in ubuntu that use configglue; and now they're both broken :)
[19:01] <barry> dobey: yeah :(
[19:02] <sarnold> unixabg: I'm not entirely sure how you'd use it either, but it -is- a mechanism to overlay one FS on top of another
[19:36] <unixabg> sarnold: I took a quick look at casper and that is where the casper-rw things occur.
[19:37] <unixabg> I may just have to remaster and script in mounting overlayfs as read only in the iso. I will have to think about what
[19:37] <unixabg> the path of least work would be to stack on stock images.
[19:40] <ximion> cjwatson: hi! from the discussion about the Ubuntu app-installer, are you planning to use PackageKit (the daemon) in Ubuntu?
[19:52] <dobey> kenvandine: btw, what's supposed to start friends-service on login?
[19:53] <robru> dobey, launching friends-app will start friends-service if it's not already running
[19:53] <dobey> robru: i don't have friends-app installed. and i don't want it (nor do i want to have to run it every time i log in). it seems like friends-service should be started on login, like gwibber-service used to be, even without the app running/installed
[19:54] <robru> dobey, it might be, I'm not sure. ken wrote most of friends-service so it's all his fault ;-)
[19:54] <dobey> i just want the notifications when someone sends me a DM or @mention
[19:55] <kenvandine> the lens does
[19:55] <dobey> bah
[19:55] <dobey> that doesn't work very well if there is no lens :)
[19:55] <kenvandine> indeed
[19:56] <kenvandine> but we always have the lens :)
[19:56] <dobey> why doesn't friends-service just have an autostart file?
[19:56] <dobey> kenvandine: gnome-shell doesn't have lenses
[19:56] <kenvandine> i'd take a patch adding autostart based on a gsettings key
[19:56] <dobey> why gsettings?
[19:56] <kenvandine> gwibber used to do that
[19:57] <kenvandine> we don't want it to always start
[19:57] <kenvandine> only for people that want it
[19:57] <dobey> people who don't want it can apt-get remove it :)
[19:57] <kenvandine> AutostartCondition=GSettings org.gwibber.preferences autostart
[19:57] <kenvandine> X-GNOME-Autostart-Delay=30
[19:57] <kenvandine> is what we had before
[19:58] <slangasek> not if it's installed by default in a read-only phone image, they can't
[19:58] <slangasek> (is it?  I don't know whether it is, but I'm assuming it would be)
[19:59] <dobey> slangasek: doesn't the phone UI even do xdg autostart?
[19:59] <dobey> err, does even
[19:59] <slangasek> that's not the point
[19:59] <slangasek> oh
[20:00] <slangasek> sorry, the inversion makes the difference ;)
[20:00] <dobey> right :)
[20:00] <slangasek> I don't know that it *currently* does xdg autostart, but I wouldn't assume that it won't do so in the future
[20:01] <kenvandine> the phone autostarts it differently anyway
[20:01] <kenvandine> but regardless, it is kind of nice to provide an easy way to disable it
[20:01] <dobey> i didn't know AutostartCondition existed though. when did that get added?
[20:01] <kenvandine> forever ago :)
[20:01] <dobey> and how does it work?
[20:01] <kenvandine> it only autostarts if the condition is true
[20:02] <pindonga> dobey, barry I think I have an MP ready for review that get's rid of the backported configparser
[20:02] <dobey> kenvandine: so it's a Exec style line? because "GSettings" isn't a command :)
[20:02] <kenvandine> right
[20:02] <kenvandine> it doesn't run a command
[20:02] <kenvandine> GSettings is one of the supported sources
[20:03] <barry> pindonga: assign me to review it and i'll look asap
[20:03] <barry> pindonga: and thanks!
[20:03] <dobey> kenvandine: and there is no AutostartCondition mentioned in the spec
[20:03] <dobey> kenvandine: so where is it documented?
[20:03] <kenvandine> i swear i've seen it in the spec before
[20:04] <dobey> kenvandine: i just looked at the -latest.html on stadnards.freedesktop.org for both autostart and desktop file specs, and no mention in either one :)
[20:05] <kenvandine> dobey, maybe it's gnome specific then
[20:05] <kenvandine> but no X-GNOME
[20:06] <kenvandine> AutostartCondition is an extension of the Desktop Application Autostart Specification proposed by Dan Winship: http://lists.freedesktop.org/archives/xdg/2007-January/007436.html
[20:06] <kenvandine> dobey, that's from https://wiki.gnome.org/SessionManagement/GnomeSession
[20:08] <dobey> ugh
[20:09] <kenvandine> proposed 6 years ago... love how fast xdg moves :)
[20:10] <dobey> well it just means that things not using gnome-session will just ignore the key, or fail to do anything because the file has an invalid key
[20:10] <dobey> yay collaboration!
[20:10] <kenvandine> kde might have implemented it too
[20:10] <kenvandine> someone from trolltech +1'd it :)
[20:11] <pindonga> barry, https://code.launchpad.net/~ricardokirkner/configglue/from-future-remove-configparser/+merge/173806
[20:11] <slangasek> kenvandine: the problem is, this proposed change doesn't require introducing a new system-level directory with semantics that no one understands; figure out how to make this use a new directory and it'll go right into xdg ;)
[20:12] <barry> pindonga: tabbed up :)
[20:14] <kenvandine> slangasek, :-D
[20:22] <smoser> hey...
[20:22] <smoser> can someone tell me if i'm just doing something wrong
[20:22] <smoser> i put a file '/etc/init/walinuxagent.conf.override'
[20:22] <smoser> and in it 'manual'
[20:22] <smoser> but it seems to be starting
[20:23] <smoser> is that right?
[20:24] <sarnold> smoser: looks like walinuxagent.override: http://upstart.ubuntu.com/cookbook/#override-files
[20:24] <smoser> ah.
[20:24] <smoser> thank you.
[20:25] <smoser> sarnold, that worked. thanks.
[20:25] <sarnold> smoser: woot :)
[20:28] <jtaylor> why doesn't launchpad pick up charybdis from unstable? (try  syncpackage --force charybdis)
[20:29] <jtaylor> it isn't listed as importer failure
[20:34] <cjwatson> ximion: I have no control of or stake either way in what we use in the rest of Ubuntu; we're not using either PK or aptdaemon in Ubuntu Touch right now, so I'm free to choose either for the moment.  It'll be at least a few months before what I'm doing matters for Ubuntu desktop
[20:35] <cjwatson> jtaylor: which importer?
[20:35] <ajmitch> jtaylor: looks like LP may not have seen the updated debian version of charybdis, for whatever reason.
[20:35] <cjwatson> jtaylor: (package-import.ubuntu.com has nothing to do with what syncpackage looks at)
[20:36] <ajmitch> does syncpackage still use what's shown on launchpad.net/debian/+source/charybdis ?
[20:36] <jdstrand> tedg: hey, so I tried initctl, and desktop-exec dumped core
[20:36] <cjwatson> ajmitch: yes
[20:36] <cjwatson> http://paste.ubuntu.com/5859584/
[20:36] <tedg> jdstrand, Hah, oops.  That's a bug :-)
[20:36] <cjwatson> ^- import failure for that package
[20:37] <jdstrand> tedg: I then tried launching using what /var/crash told me: /usr/lib/x86_64-linux-gnu/upstart-app-launch//desktop-exec ubuntu-calendar-app
[20:37] <jdstrand> same result
[20:37] <tedg> jdstrand, Can you send me your modified desktop file?
[20:37] <jdstrand> I then removed XCanonicalAppArmorProfile. same thing
[20:37] <cjwatson> the oops just has that same traceback
[20:37] <cjwatson> dpkg-source: warning: diff `charybdis-3.4.2/debian/patches/gnutls30' patches file charybdis-3.4.2/libratbox/configure.ac twice
[20:38] <cjwatson> may not be helping
[20:38] <jdstrand> tedg: yeah
[20:38] <cjwatson> I suspect the version of dpkg-dev on iron barfs on that
[20:38] <cjwatson> dpkg-source: error: diff `charybdis-3.4.2/debian/patches/gnutls30' patches file charybdis-3.4.2/libratbox/configure.ac twice
[20:38] <cjwatson> [cjwatson@amber(lucid-i386) ~]$
[20:38] <cjwatson> jtaylor: ^- reason
[20:38] <jtaylor> thx
[20:38] <jtaylor> how to fix, ask debian maintainer to fix it?
[20:39] <cjwatson> yes
[20:39] <slangasek> is that debian/patches/series.ubuntu? :P
[20:39] <jdstrand> tedg: http://paste.ubuntu.com/5859591/
[20:39] <cjwatson> since it's a warning even in Debian
[20:39] <cjwatson> slangasek: nope
[20:39] <slangasek> huh, ok
[20:39] <cjwatson> although that's another common-ish cause of this kind of thing
[20:39]  * jtaylor filing bug
[20:39] <jdstrand> tedg: I can help you setup what you need to test apparmor (though it is in my last two emails)
[20:40] <cjwatson> jtaylor: harder approach: backport the changes that turned that from an error to a warning to lucid
[20:40] <jdstrand> tedg: that said-- is there an expectation that XCanonicalAppArmorProfile will be available for the demo?
[20:40] <jtaylor> or update that machine to precise? :)
[20:40] <tedg> jdstrand, No apparmor needed there as that only parses the file.
[20:40] <cjwatson> or wait for the wheels to grind slowly for LP to be upgraded to precise
[20:40] <cjwatson> but it's not remotely trivial
[20:40] <cjwatson> (it is in progress - slowly)
[20:41] <jdstrand> tedg: otherwise, I should move to something else and stop bothering you about an interim solution :)
[20:41] <tedg> jdstrand, Not sure, I can't clear a clean answer on what the demo will include.  Sounds like it...
[20:41] <tedg> jdstrand, I was told putting Unity 8 under Upstart was "trivial" but yet it's not done.
[20:41] <cjwatson> backporting the dpkg change isn't necessarily a dreadful idea, but it would be quicker to get the Debian package fixed, I'm sure
[20:41] <jdstrand> ricmm_: ^ thoughts?
[20:42] <jdstrand> tedg: I heard today it will include the SDK building a click package
[20:43] <tedg> jdstrand, Cool, I can't wait to see this demo :-)
[20:43] <jdstrand> tedg: which implies things should work without hacks (to me anyway). though hacking the sdk to do soemthing to launch under confinement is still possible of course
[20:43] <jdstrand> it keeps expanding :)
[20:43] <jdstrand> tedg: I was trying hard to keep application lifecycle out of it
[20:43] <jdstrand> but click, lifecycle and sdk are so closely related
[20:43] <jdstrand> anyhoo
[20:44] <jdstrand> we can resort to a hack in the sdk in its build click package part
[20:45] <tedg> jdstrand, Hmm, that doesn't crash for me :-(
[20:45] <tedg> It's wrong, but no core.
[20:46] <tedg> jdstrand, Can you pastebin the stacktrace?
[20:46] <tedg> jdstrand, You're doing desktop-exec ubuntu-calendar-app, right?
[20:48] <jdstrand> tedg: fyi, this is on amd64
[20:49] <jdstrand> this is from the command line: http://paste.ubuntu.com/5859629/
[20:51] <tedg> jdstrand, Ah, that's just a g_error abort stacktrace.
[20:51] <tedg> jdstrand, Where did you put ubuntu-calendar-app.desktop ?
[20:51]  * jdstrand is working on the other
[20:52] <jdstrand> tedg: I installed ubuntu-calendar-app via the coreapps ppa (http://ppa.launchpad.net/ubuntu-touch-coreapps-drivers/daily/ubuntu)
[20:52] <jdstrand> tedg: it is in /usr/share/applications
[20:53] <jdstrand> /usr/share/applications/ubuntu-calculator-app.desktop
[20:54] <tedg> jdstrand, calculator or calendar?
[20:54] <dobey> hrmm, i wonder what the quickest way to become a debian maintainer for a package is.
[20:54] <tedg> dobey, run your car engine to speed up the heat death of the universe ;-)
[20:55] <dobey> tedg: just one of them, or all of them?
[20:56] <tedg> dobey, As many as you can afford.
[20:56] <ximion> cjwatson: okay... because the current direction does look a bit confusing...
[20:56] <dobey> that would only burn the earth anyway, not the whole universe; which will most likely actually freeze to death
[20:56] <slangasek> dobey: pick a package no one else cares about? :)
[20:56] <ximion> a PK backend cannot be used by Aptdaemon
[20:57] <dobey> slangasek: i thought i did, but someone merged it into debian from ubuntu, so now i guess i need to get privs to upload it to debian, and then sync it over
[20:57] <slangasek> well, you don't *have* to ;)
[20:58] <dobey> true
[20:58] <slangasek> if you were already maintaining it in Ubuntu, you can continue to do so
[20:58] <ximion> cjwatson: also, there can only be one PK backend at a time. For Listaller, we developed a plugin API (was very time-consuming...) to make it possible to integrate LI into PK. To get full integration, Ubuntu might want to look at this API (we created a multi-purpose API for almost any needs)
[20:58] <dobey> but merging and updating can be pain :)
[20:58] <slangasek> becoming the maintainer in Debian just so you can sync it to Ubuntu seems a bit odd
[20:59] <dobey> slangasek: well, isn't the preferred way to do things, to update them in debian and sync, if they are in debian, and we have no need to maintain a diff from what is in debian?
[21:00] <slangasek> dobey: yes, but the trade-off is the inconvenience of someone who already has upload rights in Ubuntu now having to get upload rights to Debian to continue maintaining it
[21:00] <dobey> indeed
[21:00] <slangasek> generally speaking, it's a good thing to have as much of the maintenance happen as possible in Debian, but there *are* tradeoffs
[21:01] <jdstrand> tedg: ok, apparently I am an idiot wrt to the crash
[21:02] <jdstrand> tedg: I did mistype as calendar somewhere along the way
[21:02] <tedg> jdstrand, Ah good :-)  /me wipes brow
[21:02] <tedg> jdstrand, It looks like the output ends on qmlscene, which is a bug and fixed on a branch.  I need to find a reviewer for it.
[21:03] <jdstrand> tedg: tedg well, I think there might still be an issue? initctl emit application-start APP_ID=ubuntu-calendar-app does crash
[21:03] <tedg> jdstrand, Yeah, I probably should change the error reporting to report a recoverable error.
[21:03] <jdstrand> ah, /usr/share/applications/ubuntu-calendar-app.desktop does not exist
[21:04] <jdstrand> heh, ubuntu-calendar-app is essentially an empty package
[21:04] <jdstrand> tedg: so, there is a bug for you :)
[21:04] <tedg> Wonder if I can trace who sent the upstart event and blame them? /me schemes
[21:05] <jdstrand> tedg: now that all that is straightened out. initctl emit application-start APP_ID=ubuntu-calculator-app does launch the calculator (yea!)
[21:05] <jdstrand> tedg: but does not launch under confinement
[21:05] <tedg> jdstrand, What does the desktop-exec return with the calculator?
[21:06] <tedg> jdstrand, It should have the aa-exec line.
[21:06] <jdstrand> yeah, it does
[21:06] <jdstrand> $ /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec ubuntu-calculator-app
[21:06] <jdstrand> aa-exec -p "ubuntu-calculator-app" -- qmlscene
[21:06] <tedg> Hah, then it's an apparmor issue ;-)
[21:07] <jdstrand> tedg: should that be qmlscene <qml file>?
[21:07] <tedg> jdstrand, Yeah, that's fixed in lp:~ted/upstart-app-launch/uris, but hasn't been reviewed yet.
[21:09] <jdstrand> tedg: so, maybe that is why. if I use aa-exec -p "ubuntu-calculator-app" -- qmlscene /usr/share/ubuntu-calculator-app/ubuntu-calculator-app.qml, it works
[21:09] <jdstrand> tedg: so it is an upstart-app-launch problem :)
[21:09] <jdstrand> tedg: I have finger guns too
[21:10] <tedg> jdstrand, Ah, okay.  Yes, I'd expect that to be the issue then.  If you want to grab that branch you can verify.
[21:10] <tedg> jdstrand, It's inline packaged so it's just a bzr bd to build it.
[21:10] <jdstrand> tedg: ack thanks. I'll respond to the thread in a bit. thanks :)
[21:10] <tedg> jdstrand, I did verify on the desktop file that you sent me that it added the QML file though.
[21:11] <tedg> jdstrand, So I'm pretty confident that branch fixes it.
[21:11] <jdstrand> rocking
[21:11] <jdstrand> once that is there, then all that's left is desktop-exec being used in the demo
[21:11] <jdstrand> (for this part)
[21:12] <tedg> jdstrand, Yeah, I haven't pushed the Unity guys there because today they'd have to shell out to initctl, while in a few days they'll be able to use libupstart, which is much better.
[21:12] <jdstrand> that's fine. I'm not pushing anything either, just trying to stay on top of the various threads :)
[21:13] <jdstrand> tedg: thanks for the help
[21:13] <tedg> np
[21:14] <dobey> does "Tests-Directory: ." in debian/tests/control work (and do what I think it should do)?
[21:28] <tedg> slangasek, Can an upstart event have multiple values for the same property?
[21:29] <tedg> slangasek, i.e.  foo-event BAR=fu BAR=foo, so then the listener could trigger on one value, either one.
[21:30] <dobey> is there a way to get autopkgtests run in pbuilder when it builds the package?
[21:33] <jtaylor> dobey: I have a script to run adt in pbuilder, should not be hard to adapt it to do it automatically
[21:34] <dobey> maybe i can just do it locally
[21:34] <jtaylor> its still horrendous bad code but I jut can't find the time to cleanit up and release it proper :/
[21:34] <jtaylor> http://paste.ubuntu.com/5859759/
[21:36] <jtaylor> wait I probably already gave that to you didn't I? I should stop pushing my aweful stuf :(
[21:36] <jtaylor> (it does work well though)
[21:36] <dobey> i haven't seen it before, no
[21:37] <dobey> oh nice
[21:37] <dobey> NameError: global name 'atmostone' is not defined
[21:37] <dobey> :-/
[21:38] <jtaylor> there is also sadt.py by jwilk, but it does not deal with dependencies or pbuilder (last I checked): https://bitbucket.org/jwilk/debian-misc/
[21:38] <jtaylor> but it might be a better starting point
[21:42] <dobey> i can't even run adt-run locally
[21:43] <dobey> i am surprised it works at all anywhere :-/
[21:43] <jtaylor> works for me, but its to heavy for practical use
[21:44] <dobey> i must be using something nobody else uses then, because this code is definitely broken :)
[21:45] <dobey> anyway, after fixing the brokenness there, it seems to work now
[21:45] <dobey> and it does what i expected (aside from the not working part), so yay!
[23:05] <slangasek> tedg: multiple values for the same property> AFAIK the answer is no