[00:52] <micahg> chrisccoulson: jbicha: I was going to discuss with skaet actually, I figured to play it by ear
[00:52] <micahg> re 16 in quantal
[00:53] <micahg> chrisccoulson is right not to include it ATM though
[00:53] <doko_> robert_ancell, would you mind uploading non-change uploads for the nth poppler transition?
 Oh, thank god, I was worried we might go a whole month without a poppler ABI bump.
 I wonder if maybe we should rename PlusOneMaint to PopplerAndEDSMaint.
 just staff two people from -desktop for the team, there's not much to do for -foundations
[00:57] <doko_> jasoncwarner_, seb128: ^^^ pretty please let's find a solution for this. this kind of stuff is pushed into the development releases, otoh I do hear that desktop doesn't stuff the maint+1 team very well
[02:16] <robert_ancell> doko_, yes, was waiting for it to be built
[02:30] <TheMuso> jbicha: You around by any chance?
[02:44] <jbicha> TheMuso: yes
[02:45] <TheMuso> jbicha: Ah great. Have you seen this branch, an alternate fix to your own for GDM autologin: lp:~darkxst/casper/fix-gdm-autologin-lp1046630
[02:46] <TheMuso> jbicha: THe same thing done somewhat differently, although the persistance check is removed, which I disagree with.
[02:46] <TheMuso> I'm wondering whether you are ok with that, and whether you also want the extra gsettings change he included.
[02:47] <jbicha> TheMuso: yes, his changes are fine
[02:48] <TheMuso> jbicha: What do you think about the removal of persistance checking?
[02:51] <jbicha> I believe it's not really needed with the sed lines; and the the kdm & lxdm sections don't have that check
[02:51] <TheMuso> Fair enough, will take his branch wholesale then.
[02:51] <TheMuso> Thanks.
[02:52] <jbicha> thanks! it was a headache trying to patch casper in our build script
[02:52]  * TheMuso nods.
[02:53] <TheMuso> Ok, I'll mark your branch merged, even though its not, because the end result is the same. :)
[02:53] <TheMuso> jbicha: Oh, and please add a changelog entry next time.
[02:53] <TheMuso> Thanks again.
[03:04] <jbicha> robert_ancell: could you sponsor https://code.launchpad.net/~ubuntu-desktop/+junk/ubuntu-default-settings
[03:08] <robert_ancell> jbicha, does it need to conflict with metacity, gsettings-desktop-schemas etc?
[03:10] <jbicha> no, you can have multiple overrides for the same setting
[03:10] <jbicha> and the files are named differently so that doesn't conflict either
[03:11] <robert_ancell> jbicha, ok, cool
[03:12] <robert_ancell> jbicha, btw I registered lp.net/ubuntu-default-settings so you can push to lp:~jbicha/ubuntu-default-settings/blah in the future
[03:25] <robert_ancell> jbicha, uploaded
[03:39] <pitti> Bonjour
[03:40] <robert_ancell> jbicha, btw have you considered putting anjuta on the ubuntu gnome image?
[03:44] <jbicha> robert_ancell: I hadn't considered it yet http://paste.ubuntu.com/1199894/
[03:45] <robert_ancell> jbicha, asking because it's considered a standard app: http://ftp.gnome.org/pub/GNOME/teams/releng/3.5.91/versions
[03:45] <robert_ancell> along with devhelp, nemiver, rygel, accerciser
[03:46] <robert_ancell> glade, gnome-devel-docs etc
[03:47] <jbicha> nemiver & rygel aren't useful enough
[03:48] <jbicha> installing gnome-devel pulls in a lot but it works too http://paste.ubuntu.com/1199900/
[03:49] <jbicha> the definition of GNOME apps is a bit fuzzy
[03:50] <robert_ancell> yeah
[03:53] <jbicha> like the Abiword v. LibreOffice discussion on desktop-devel which didn't really conclude anything
[03:55] <jbicha> ooh, vinagre & Boxes are both listed
[03:56] <thumper> hi ho
[03:56] <thumper> who could I bitch to about libpixman?
[03:56] <thumper> it hates valgrind
[03:58] <robert_ancell> thumper, upstream?
[03:59] <thumper> hmm...
[03:59] <thumper> I'm wondering if I'm being overly harsh
[03:59] <thumper> perhaps we just suck at using it
[04:15] <RAOF> thumper: Upstream would be good; failing that, it's an X lib.
[04:22] <dglass> Question about python-evolution: LP: #1041785 seems to be fixed by adding python-gnome2 as a dependency for python-evolution. I'm not sure if this is the correct fix or not. Is anyone working on this?
[04:22] <micahg> jbicha: speaking of rygel, are you planning on fixing that any time soon? :)
[04:22] <dglass> I've been using python-evolution for another package (https://bugs.launchpad.net/ubuntu/+source/wakeup) which has evolution capabilities broken in quantal because of this bug.
[05:03] <didrocks> good morning
[05:48] <pitti> bonjour didrocks, ca va?
[05:49] <didrocks> guten morgen pitti. I think I caught a cold :/ not really big yet (just some coughing), but it seems to evolve quickly
[05:49] <didrocks> yourself?
[05:49] <pitti> argh, I'm just over that -- good luck!
[05:50] <pitti> je vais bien!
[05:50] <pitti> I've got some sore muscles (but it feels good), from the first Taekwondo training after the rather long summer break
[05:50] <pitti> high time to get into exercise again :)
[05:51] <pitti> oh, c'est l'anniversaire de Seb
[05:52] <didrocks> heh, indeed, getting back to training is quite hard :)
[05:52] <didrocks> oui, c'est son anniversaire :)
[05:53]  * pitti sends him some greetings
[05:54] <robert_ancell> Sweetshark, hey, can you reupload libreoffice so it builds against the latest poppler? I'm not keen to download 300M just to do a no-change upload :)
[05:54] <pitti> didrocks: et demain est le ton, oui?
[05:54] <didrocks> pitti: en effet :)
[05:55] <pitti> didrocks: hier, c'était de Jibel, what a coincidence ;)
[05:56] <didrocks> pitti: oh really? Didn't know about that one! Will catch him today :)
[05:56] <didrocks> pitti: september has a high birth rate AFAIK ;)
[05:56] <pitti> grande fête d'anniversaire des français :)
[05:56] <didrocks> ahah :)
[06:14] <pitti> didrocks: do you guys really say "quatre-vingt-seize", not something like "nonante-six"?
[06:15] <didrocks> pitti: yeah, quatre-ving-seize :) Only elderly and belgium people are telling "nonante-…"
[06:15] <pitti> wow, arithmetic :)
[06:16] <pitti> didrocks: ah, the dictionary says that's "swiss/belgium", indeed
[06:16] <didrocks> at least, it's logicial :)
[06:16] <didrocks> logical*
[06:16] <pitti> (also for huitante/octante)
[06:16] <pitti> fascinating
[06:17] <didrocks> oh great, my session crashed
[06:17] <didrocks> well, compiz first
[06:17] <didrocks> then, went to tty1, start metacity
[06:17] <didrocks> and boum, no more session
[06:20] <didrocks> ok, compiz is still crazy, restarting
[06:20] <didrocks> wonder if it's not the mesa driver…
[06:20] <didrocks> (and I'm running in llvmpipe then now
[06:20] <didrocks> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)
[06:21] <didrocks> yep, that's the cause, so something in mesa made compiz crashed
[06:21] <didrocks> then, as my machine is quite beefy, I just see high CPU with llvmpipe, not that much slowliness
[06:21] <didrocks> anyway, restart, brb
[06:58] <pitti> mvo: good morning
[06:59] <pitti> mvo: seems the s-c tests are much happier now, thanks! the only remaining failure is once again the "de.archive.u.c." resolution problem, i. e. firewall
[06:59] <pitti> mvo: I guess this test should just be skipped in the DC?
[07:08] <mvo> pitti: sure, I will add a skip decorator
[07:10] <chrisccoulson> good morning everyone
[07:10] <pitti> mvo: what are you going to test/ urlopen('http://de.archive.ubuntu.com/ubuntu/') and skipUnless('dists/</a>') in the contents, or something like that?
[07:10] <mvo> pitti: it can talk to archive.u.c?
[07:10] <pitti> mvo: yes, that works
[07:10] <didrocks> good morning chrisccoulson
[07:10] <pitti> mvo: presumably also to ppa.launchpad.net, if that helps
[07:10] <chrisccoulson> hey didrocks, how are you?
[07:10] <mvo> pitti: aha, yeah, good point
[07:11] <didrocks> chrisccoulson: coughing more and more, but fine otherwise :/
[07:11] <didrocks> chrisccoulson: yourself?
[07:11] <chrisccoulson> didrocks, yeah, not too bad i guess
[07:11] <pitti> hey chrisccoulson
[07:11] <chrisccoulson> hi pitti, how are you?
[07:11] <mvo> hey chrisccoulson, good morning
[07:11] <chrisccoulson> hi mvo, good morning
[07:12] <pitti> didrocks: I dragged my cold for almost two weeks -- maybe better to take the day lightly, get into a steam bath, and sleep it off?
[07:12] <pitti> that's what eventually helped me
[07:12] <pitti> admitting that one day of proper recovery is better than ignoring it for a week :(
[07:12] <pitti> chrisccoulson: I'm fine, thanks!
[07:18] <didrocks> pitti: let's see when it will be worse, still having a lot of bugs for the release team to triage and I'm supposively on the +1 shift without having any time for it yet
[07:18] <didrocks> in addition to the utouch rename SRUs… :/
[07:58] <dholbach> hiya
[07:58] <dholbach> any chance of getting libappindicator3 multi-arched?
[08:33] <didrocks> dholbach: hey, sorry, not really sure, we are quite rather focussing on bug fixing right now and already don't have enough people to do what we need to do
[08:33] <didrocks> dholbach: why do you need it multi-arched btw?
[08:33]  * didrocks finally won over pbuilder, phew
[08:50] <pitti> fun -- the first test that I set up for UI sleep integration tests fails (org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout)
[08:52] <didrocks> showing that the test was needed :)
[09:27] <cyphermox> Hey didrocks. We should be able to get rid of a few eds nbs today by removing packages
[09:27] <cyphermox> I'll get you a list once I'm done breakfast and on my laptop rather than my phone
[09:30] <arand> Does "XB-Screenshot-Url:" work for all packages or only for those in "extras"?
[09:31] <didrocks> cyphermox: excellent thanks!
[09:31] <xnox> arand: I saw a screenshot load up for skype package downloaded from skype.com check their debs?
[09:32] <didrocks> pitti: what's the policy in case you have a library which changed it's soname (API breakage in that case), and a software which dep on it has no upstream activity for 7 years, I can find no patch online for the new API as well
[09:32] <didrocks> (but it's still in debian, we are in sync)
[09:38] <pitti> didrocks: I'd say, apply a patch in Ubuntu and send it to the Debian BTS (so that it's available when they upgrade to the new lib as well)
[09:40] <didrocks> pitti: oupsss, sorry, s/can/can't/
[09:40] <didrocks> or "can find no patch" as I told, actually :)
[09:40] <pitti> "can find no patch" sounds right? :-)
[09:41] <didrocks> yeah, so there is no patch for the new API, I wonder what you meant by "apply a patch in Ubuntu" :)
[09:41] <tsimpson> DIY :)
[09:42] <didrocks> tsimpson: well, I don't know at all the software/nor how to test it, so seems pointless to do it
[09:49] <arand> xnox: Their debs have nothing that looks related.
[09:50] <xnox> =(
[09:50] <xnox> software-centre must be smart and pulls a screenshot for skype from somewhere....
[09:51] <arand> It must be https://apps.ubuntu.com/cat/applications/skype/
[09:54] <arand> But the partners repo sky doesn't have any either... :/
[09:54] <arand> *skype
[09:56] <pitti> didrocks: you mean the library changed API that heavily?
[09:56] <pitti> didrocks: why did that happen after FF? (or is that NBS case already that old?)
[09:57] <pitti> didrocks: there's always the option of removing old and crufty packages as well, of course; what lib and package are we talking about?
[09:57] <arand> Hmm, they seem to be on http://screenshots.ubuntu.com/package/skype actually...
[10:07] <didrocks> pitti: I'm just looking at NBS, seems to have been there for some time: http://people.canonical.com/~ubuntu-archive/nbs.html
[10:07] <didrocks> libevocosm-3.1-1
[10:07] <didrocks> which is the lib
[10:07] <didrocks> and acovea not working with the newer version
[10:08] <pitti> didrocks: yeah, seems same problem in Debian
[10:08] <pitti> http://qa.debian.org/popcon.php?package=acovea *yawn*
[10:08]  * pitti parle "kill it"
[10:12] <didrocks> pitti: that was my guess (not really popular), thanks! :-)
[10:26] <dholbach> can somebody please reply to https://twitter.com/marcosbarbosa/statuses/245652886686670848?
[10:32] <mvo> pitti: is there a way to get the pygi version in use? the best I found was GObject._glib.glib_version but that is not the pygi but the glib version :/
[10:34] <mvo> pitti: aha! quantal has that as gi.version_info bu t not precise
[10:36] <didrocks> dholbach: that would be when mterry is around :)
[10:36] <dholbach> ok cool
[10:36] <pitti> mvo: right, version_info was only added recently
[10:37] <pitti> mvo: is that enough (pre-quantal and correct version since quantal)?
[10:37] <pitti> mvo: otherwise you might need a fallback to dpkg -l?
[10:39] <mvo> pitti: its about https://code.launchpad.net/~mvo/dee/small-python-fixes/+merge/123763 at some point python-gi changed and upstream wants to keep the override file version agnostic, I will ask them if precise/quantal is good enough for the split
[10:41] <pitti> mvo: another hack would be to intercept the TypeError (or AttributeError?) and fall back to the old method
[10:41] <pitti> EAFP
[10:42] <mvo> pitti: yeah, I mentioned that in the MP as well as a option, the only downside is that it might shadow real typerrorrs, I will let upstream decide :) IMO it should simply require the new python-gi (/me is lazy)
[10:42]  * mvo looks up EAFP
[10:42] <pitti> "easier to ask for forgiveness than permission"
[10:42] <pitti> which is the pythonic approach
[10:42]  * mvo nods
[10:42] <pitti> the other is "look before you leap"
[10:42] <pitti> i. e. "if (I can do this) { do }"
[10:43] <pitti> mvo: yeah, so I guess it shoudl be aright to check version_info, and assume the old method if it's not there
[10:43] <pitti> "alright"
[10:43]  * mvo nods
[10:43] <mvo> pitti: thanks for your help
[10:44] <pitti> de rien :)
[12:51] <didrocks> chrisccoulson: how bad would you feel if we remove thunderbird-couchdb (because of the EDS big API changes)?
[12:52] <chrisccoulson> didrocks, i'd be really happy ;)
[12:52] <chrisccoulson> didrocks, bug 1040839
[12:52] <ubot2> Launchpad bug 1040839 in thunderbird-couchdb "Thunderbird hangs accessing eds on startup" [High,Triaged] https://launchpad.net/bugs/1040839
[12:52] <didrocks> chrisccoulson: if I can make you happy AND close a bug… :-)
[12:53] <pitti> didrocks has a quad-damage today!
[12:53] <didrocks> pitti: never used remove-package that many in a day
[12:54] <didrocks> (just flushed evolution-exchange, evolution-couchdb)
[12:54] <didrocks> and this is only the beginning!
[12:54] <didrocks> the EDS API change are a big chunk and nobody maintains that
[12:55] <pitti> didrocks: oh, evo-exchange is gone as well?
[12:55] <pitti> that seemed to be quite popular
[12:56] <didrocks> pitti: yeah, no upstream updates for long, removed from fedora, debian confirms there is no maintainance as well
[12:56] <didrocks> evolution-ews seems to be maintained though
[12:56] <didrocks> (which is the 2007+ protocol as cyphermox explained to me)
[12:57] <cyphermox> yeah, pitti, I agree it seemed pretty popular to me too
[12:58] <cyphermox> didrocks: can we leave it at that for now, I'll look at the other packages and let you know what else would be a candidate for obliteration
[12:58] <cyphermox> I hope not too many
[12:58] <cyphermox> contact and dates used to have been removed from testing, but it seems there was at least one QA upload since so they're back
[13:00] <didrocks> cyphermox: ok, do you think you will have time to look at that before EOW?
[13:00] <cyphermox> yes, definitely
[13:00] <cyphermox> by that you mean all NBS for EDS, right? :)
[13:00] <didrocks> yeah, all rdepends for this evolution stack :)
[13:00] <cyphermox> eep
[13:00] <cyphermox> hehe
[13:00] <didrocks> ebook and ecal included :)
[13:01] <cyphermox> depending on how long it will take to fix ekiga and some of those
[13:01] <didrocks> cyphermox: let's see if upstream worked on those
[13:01] <cyphermox> yeah
[13:01] <cyphermox> but I know some didn't
[13:01] <didrocks> like?
[13:01] <cyphermox> fortunately in some places we can just disable them
[13:02] <cyphermox> can't recall
[13:02] <didrocks> yeah, that's an option
[13:02] <didrocks> I this the e-d-s integration is optional for most of them
[13:02] <cyphermox> but I know some aren't ported to EDS 3.5 yet
[13:02] <cyphermox> oh, I thought you mean EOD
[13:03] <cyphermox> EOD is agressive. EOW is very reasonable :)
[13:03] <didrocks> no, EOW ;)
[13:03] <jbicha> ekiga has a new release with support for eds 3.5.3
[13:04] <didrocks> jbicha: I'm just looking trunk
[13:04] <didrocks> right, excellent :)
[13:05] <didrocks> will need a FFe/UIFe I think
[13:05] <jbicha> but we don't want to bother with the new ptlib/opal, do we?
[13:06] <didrocks> argh, 3.10.7 for 3.10.4
[13:06] <didrocks> let me see if I can just backport the e-d-s commit
[13:06] <didrocks> seems to be http://git.gnome.org/browse/ekiga/commit/?id=d84271d706408357d3ec8a36be4db7160e0823e4
[13:10] <cyphermox> jbicha: might, I recall I had to mess with it for something this cycle
[13:12] <cyphermox> didrocks: you looking at ekiga then?
[13:13] <didrocks> cyphermox: yeah
[13:13] <cyphermox> ok
[13:23] <kenvandine> davmor2, i am about to upload the fix for the google auth bug :)
[13:25] <didrocks> cyphermox: taking care of glabels
[13:25] <cyphermox> ok, I'm looking at obexd-server
[13:25] <didrocks> kenvandine: I discussed it earlier with mardy. Thanks kenvandine :)
[13:25] <cyphermox> brb
[13:25] <kenvandine> didrocks, cool, you hit that bug too?
[13:26] <didrocks> kenvandine: yep
[13:27] <kenvandine> jasoncwarner_ will be happy too :)
[13:49] <davmor2> kenvandine: Woohoo!
[14:15] <didrocks> cyphermox: I'm taking care of almanah
[14:17] <dholbach> mterry, didrocks suggested you might be able to reply to https://twitter.com/marcosbarbosa/statuses/245652886686670848?
[14:18] <didrocks> dholbach: I think there is a report that it's available today (just one hour ago ;))
[14:18] <cyphermox> oh, fun, LDAP login yay!
[14:18] <didrocks> dholbach: http://www.iloveubuntu.net/unity-greeter-received-remote-login-support-ubuntu-1210-default
[14:19] <dholbach> sweet
[14:19] <mterry> dholbach, didrocks: we have remote login support now, with RDP.  I don't think that's the same as AD/LDAP?  The world of connecting to windows is confusing to me
[14:19] <mterry> oh, let me read that article
[14:20] <cyphermox> didrocks: taking eweouz
[14:24] <dholbach> mterry, so is that info something I could pass on or is there a bug about ad/ldap?
[14:25] <dholbach> ... or you could reply to it :)
[14:25] <mterry> tedg, ^
[14:26] <mterry> dholbach, I need Ted to answer what remote-login-service actually supports.  I only helped integrate it into the greeter
[14:26] <dholbach> ok
[14:26] <tedg> dholbach, No we're not talking about authenticating to local accounts.
[14:26] <cyphermox> didrocks: also taking syncevolution
[14:26] <dholbach> I have no idea about this, I just received this at @ubuntudev
[14:26] <tedg> dholbach, We're building a guest account with a full screen login to a remote server.
[14:27] <didrocks> cyphermox: roger :)
[14:27] <tedg> dholbach, Really for that, you should be able to just use pam_ldap
[14:27] <kenvandine> didrocks, any tricks to run the unity tests?
[14:27] <kenvandine> make[3]: *** No rule to make target `../tests/test-gtest', needed by `tests/CMakeFiles/check'.  Stop.
[14:27] <tedg> dbarth, But, I don't think there's a nice way to configure it.  You have to go all command line and stuff.
[14:28] <tedg> sorry dbarth, dholbach
[14:28] <dholbach> ok...
[14:28] <didrocks> kenvandine: make check should be enough
[14:28] <kenvandine> :/
[14:28] <dholbach> xnox replied already: https://twitter.com/tdlk/statuses/245845463738236929
[14:28] <dholbach> great
[14:29] <kenvandine> it's not building test-gtest
[14:29] <kenvandine> but it looks like it should
[14:30] <arand> Does "XB-Screenshot-Url:" as mentioned at https://wiki.ubuntu.com/PostReleaseApps/Metadata#Add_Custom_Metadata_Fields_to_debian.2BAC8-control work for all packages or only for those in "extras"? I'm wanting to add a screenshot for an app in multiverse (contrib, hence not accepted on screenshots.debian.net).
[14:36] <mvo> pitti: I guess you are fine with the diff for lp:~mvo/aptdaemon/support-for-whitelisted-repositories now? or is there anything you would like me to change (happy to do so :)
[14:39] <cyphermox> didrocks: does this look like just bugfix to you? --> http://paste.ubuntu.com/1200661/
[14:40] <cyphermox> sorry, the commit list is quite large I agree :)
[14:44] <didrocks> cyphermox: sorry, I don't get you, you want just to backport 428a959 EDS: added support for EDS 3.5.x
[14:44] <didrocks> right?
[14:44] <didrocks> (which app is this?)
[14:44] <cyphermox> no, I don't
[14:44] <cyphermox> sorry, that's syncevolution
[14:45] <cyphermox> it needs a two more commits to cherry pick the changes
[14:45] <didrocks> ah, and you want to backport a snapshot?
[14:45] <tkamppeter> pitti, hi
[14:45] <cyphermox> but this whole list of commits would actually be a new release
[14:45] <cyphermox> jumping revision numbers
[14:45] <didrocks> cyphermox: ah, got you now
[14:45] <didrocks> let me see if the snapshot is ok
[14:46] <cyphermox> according to the version number change 1.2.99.1 -> 1.2.99.3, it would be bugfix, the commits look reasonable-ish to me too (mostly tests)
[14:46] <cyphermox> I guess I wasn't very clear with all this was I ;)
[14:46] <didrocks> yeah, I got you now, no worry :)
[14:47] <didrocks> cyphermox: looking at all the commits, it seems reasonable to me to go with latest and greatest, only bug fixing
[14:47] <cyphermox> ok
[14:47] <cyphermox> then that's what I'll do
[14:48] <didrocks> great :)
[14:48] <cyphermox> eweouz is going to need porting work, I'll get back to it
[14:48] <cyphermox> it's emacs too, I feel dirty :)
[14:50] <didrocks> heh :)
[14:50] <didrocks> with a name like that as well… ;)
[14:51] <cyphermox> lol
[14:55] <didrocks> cyphermox: what do you think about dates and contacts? those were meego projects, for the handset IIRC
[14:55] <didrocks> cyphermox: I would go for a removal personnaly
[14:56] <cyphermox> does it look like they might be maintained?
[14:57] <didrocks> cyphermox: I can't find any trunk for the past 5 minutes since the meego project was shutted down
[14:57] <cyphermox> ah right
[14:57] <cyphermox> not all of meego was shut down sadly
[14:57] <cyphermox> just enough remains to make our life complicated when it comes to finding if something is maintained
[14:57] <didrocks> heh, indeed :)
[14:58] <cyphermox> didrocks: I'd say removal; it used to be removed in Debian too, and is still orphaned
[14:58] <didrocks> cyphermox: agreed
[14:58]  * cyphermox declares this "the big EDS pruning day of '12" ;)
[14:59] <didrocks> heh :)
[14:59] <cyphermox> wish there aren't many more, I don't like removing stuff
[15:00] <didrocks> cyphermox: http://qa.debian.org/popcon.php?package=dates, http://qa.debian.org/popcon.php?package=contacts
[15:01] <didrocks> cyphermox: for stuff that are really not used and that are basically broken with few changes someone will get into it some days, don't feel sorry :)
[15:05] <tkamppeter> Anyone can help me with a packaging issue? In system-config-printer I have moved two files from system-config-printer-gnome to system-config-printer-common.
[15:08] <tkamppeter> In the debian/control section of -common I have added a Break/Replaces on the older -gnome versions and in the section for -gnome a Depends on the current -common version. If I update the packages all at once I get: http://pastebin.ubuntu.com/1200706/
[15:09] <tkamppeter> The debian/control file is here: http://pastebin.ubuntu.com/1200709/
[15:10] <xnox> when I run usb-creator in quantal I get "dbus error while communicating with UDisks"
[15:10] <xnox> is Udisks1 disabled?
[15:10] <xnox> pitti, maybe you know this?! ^^^^
[15:12] <didrocks> tkamppeter: you don't need the Breaks:
[15:12] <didrocks> tkamppeter: just get the Replaces:
[15:13] <didrocks> tkamppeter: so assuming that 1.3.11+20120807-0ubuntu7 is the version when you moved the files from -gnome to -common
[15:13] <didrocks> tkamppeter: keep the replaces field you have in system-config-printer-common and removes the Breaks: one
[15:21] <cyphermox> didrocks: still working on building syncevolution; I'm going out for an hour or so for lunch
[15:21] <didrocks> cyphermox: no worry ;)
[15:21] <didrocks> enjoy!
[15:22] <tkamppeter> didrocks, that's it. Thank you.
[15:22] <didrocks> tkamppeter: yw :)
[15:41] <kenvandine> cyphermox, you did the packaging for indicator-sync right?
[15:42] <didrocks> kenvandine: do you think you can find someone to update indicator-evolution in the PS team to latest e-d-s?
[15:42] <kenvandine> cyphermox, the bug that made you disable the tests is fixed and there are some comments on the MIR, can you look at it?  bug 1046055
[15:42] <ubot2> Launchpad bug 1046055 in indicator-sync "[MIR] indicator-sync" [Undecided,Incomplete] https://launchpad.net/bugs/1046055
[15:42] <kenvandine> didrocks, i'll try :)
[15:42] <didrocks> thanks kenvandine :)
[15:43] <kenvandine> didrocks, is there a bug for it?
[15:43] <didrocks> kenvandine: no, but I can fix that :)
[15:45] <kenvandine> didrocks, thx
[15:45] <didrocks> kenvandine: bug #1049909
[15:45] <ubot2> Launchpad bug 1049909 in evolution-indicator "evolution-indicator doesn't work with latest e-d-s" [High,Triaged] https://launchpad.net/bugs/1049909
[15:45] <didrocks> kenvandine: I put it on the release-team tracking
[16:50] <xnox> who did singon package?
[16:51] <xnox> never mind found it.
[18:35] <cyphermox> kenvandine: thanks, yeah, there's a new release too just for this IIRC; I'll upload today if possible
[18:36] <kenvandine> cyphermox, thx
[19:21] <cyphermox> kenvandine: well, now the tests pass but there are really consterning Glib Critical warnings
[19:21] <cyphermox> ;)
[19:22] <cyphermox> I'm going to run it a couple more times in sbuild before uploading though, just to be sure
[19:24] <kenvandine> cool
[19:48] <cyphermox> kenvandine: uploaded
[19:49] <kenvandine> cyphermox, can you change the MIR bug status too
[19:49] <kenvandine> as long as it's in incomplete it won't get looked at
[19:49] <kenvandine> and maybe bug mterry :)
[19:50] <cyphermox> sure
[19:50] <kenvandine> thx
[19:57] <cyphermox> mterry: ^^ I updated the bug
[19:57] <mterry> cyphermox, which bug?
[19:58] <mterry> indicator-sync, ah
[19:58] <cyphermox> ah yeah
[19:58] <cyphermox> note to self, read the whole comment next time before uploading
[19:58] <cyphermox> I could have covered the nitpicks as well :/
[20:01] <mterry> cyphermox, so the deal with pkglibexecdir is that with debhelper compat 9, we start polluting the global libexecdir (granted, in this case, the files installed there happen to be pkg-prefixed, but that's not guaranteed to be the case, and it's good practice to use a pkg folder to stuff everything in).  The reason some packages don't do that is that in compat versions less than 9, libexecdir included the package name for some dumb reason, so eve
[20:01] <mterry> rything was already prefixed.  Nowadays, that bug is fixed
[20:02] <mterry> (that is, we start polluting the global libexecdir, unless we use pkglibexecdir)
[20:02] <cyphermox> bah, whatever.
[20:03] <cyphermox> I asked for it to be fixed partly upstream before
[20:03] <cyphermox> I can definitely add the prefix manually in the install file for next upload ;)
[20:03] <mterry> well...  is there an upstream bug I can go yell at someone in?
[20:04] <cyphermox> nah, I asked charles directly
[20:05] <cyphermox>  mterry: I'll file the bugs now
[20:05] <cyphermox> bear with me, doing other stuff at the same time, so I'll let you know ;)
[20:06]  * cyphermox waves hands to try to get wpa and syncevolution to build faster
[20:08] <mdeslaur> cyphermox: try bribes :)
[20:09] <cyphermox> mdeslaur: nobody to bribes, that's on my sbuild ;_)
[20:09] <mdeslaur> oh, hehe...bribe yourself into buying a faster computer? :)
[20:09] <charles> cyphermox: are you referring to the glib warnings in the i-sync tests?
[20:09] <charles> there are tests in there that feed the public API a bunch of garbage to increase branch coverage, but it's noisy :)
[20:09] <cyphermox> charles: yeah, that's what i meant
[20:10] <cyphermox> it's kind of scary. because it looks like the tests could be failing silently
[20:10] <cyphermox> if you could reorganize the tests to make the ones that are expected to fail have a name that represents this, it would satisfy me, but I'm just being pedantic
[20:11] <charles> that's a good idea
[20:11] <cyphermox> charles: mterry: https://bugs.launchpad.net/indicator-sync/+bug/1050026
[20:11] <ubot2> Launchpad bug 1050026 in indicator-sync "install service to pkglibexecdir rather than libexecdir" [Medium,Triaged]
[20:11] <cyphermox> (needs triaging in the indicator-sync project too)
[20:12] <mterry> cyphermox, thanks!
[20:13] <charles> sounds right. the other services get installed in /usr/lib/indicator-foo/indicator-foo-service
[20:13] <cyphermox> charles: but indicator-message doesn't
[20:14] <cyphermox> we discussed this before, my fault for telling you conflicting things
[20:14] <cyphermox> that's because I get conflicting messages too :)
[20:14] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/indicator-sync/+bug/1050032
[20:14] <ubot2> Launchpad bug 1050032 in indicator-sync "incorrect call to dh_girepository" [Medium,Triaged]
[20:14] <cyphermox> mterry:  ^
[20:14] <mterry> cyphermox, charles: new package/tests fail on armhf
[20:15] <cyphermox> gah!
[20:17] <mterry> looks like it's just slower building everything than dbus-test-runner is willing to wait for
[20:17] <cyphermox> yeah
[20:17] <cyphermox> that's my fault
[20:17] <mterry> cyphermox, you weren't spinning the armhf lever fast enough?
[20:17] <mterry> :)
[20:18] <cyphermox> damn :, (
[20:18]  * cyphermox does more tests to try to figure out the sweet spot for that timeout
[20:30] <mterry> cyphermox, I see some output like "(process:17316): libsync-menu-CRITICAL **: on_got_bus: assertion `IS_SYNC_MENU_APP (user_data)' failed" when running the test suite too...
[20:33] <cyphermox> omg, that was scary
[20:33] <cyphermox> I thought I had fried my arm board :/
[20:34] <mterry> heh
[20:35] <mterry> cyphermox, I even get a timeout building locally on my i386
[20:36] <cyphermox> grr
[20:37] <cyphermox> well like I said, I'll do a bit of testing on my armhf and try to figure out a better timeout
[20:38] <cyphermox> here and on the amd64/i386 builders, 30 seconds (the default) seems good enough, but maybe I should bump it up to 60
[20:38] <cyphermox> or even 120, since it wouldn't really be so much of an issue
[20:39] <mterry> cyphermox, yeah seems like there's little cost to a hight timeout
[20:40] <mterry> charles, playing with the demo app, the on/off switch doesn't seem to work.  Does it for you?
[20:40] <mterry> (re: indicator-sync)
[20:40] <charles> mterry, yes
[20:40] <cyphermox> charles: using the binaries from the package?
[20:40] <charles> mterry: larsu was using it too, so that's at least two of us :)
[20:42] <charles> yep, if I build the sync-app-example from source and run it standalone, I get the sync indicator in unity and see the on/off switch there, and clicking it switches correctly
[20:42] <charles> mterry, what behavior are you seeing?
[20:42] <mterry> charles, hm, ok...  this is running with indicator-loader, so maybe something in that interaction is bad
[20:43] <mterry> charles, it switches from on to off and back about 6 or so times, before finally setting back to on.  So I can't switch it off
[20:43] <charles> mterry: try running the menu example in ido, for a point of comparison
[20:43] <charles> that doesn't sound good
[20:43] <mterry> charles, everything else in the demo works
[20:43] <charles> mterry: as an aside, could you clarify what you're looking for in the sync-menu project side of https://bugs.launchpad.net/indicator-sync/+bug/1050026
[20:43] <ubot2> Launchpad bug 1050026 in indicator-sync "install service to pkglibexecdir rather than libexecdir" [Medium,Triaged]
[20:44] <charles> the automake rules in there are the same as in the other indicators, so I'm not sure what you're looking for
[20:44] <mterry> charles, the other indicators are wrong too
[20:44] <charles> (and if it's broken in i-sync, is it broken everywhere else and just worked around in the packaging rules)
[20:45] <charles> mterry: could you point to a Makefile.am that does it correctly, so that I can use it as reference?
[20:45] <mterry> charles, it's just a matter of changing libexec to pkglibexec
[20:45] <mterry> charles, so in the service.in file and in the two Makefile.am's that reference it
[20:46] <mterry> charles, the reason this may seem like a new issue is because dh9 changed its default behavior
[20:46] <mterry> charles, there is a long-standing bug that debhelper will include the source package name in libexecdir, when it shouldn't
[20:46] <mterry> charles, which meant pkglibexecdir always looked like /usr/lib/package/package, which most people thought looked stupid and so didn't use it
[20:46] <mterry> charles, but dh compat level 9 fixes that, so upstreams should really use the correct variable
[20:47] <mterry> charles, let me dig up a correct Makefile.am just for clarity
[20:47] <charles> okay. So I would just replace "libexec_PROGRAMS = indicator-foo-service" with "pkglibexec_PROGRAMS = indicator-foo-service"
[20:47] <charles> iiuc
[20:48] <mterry> charles, http://bazaar.launchpad.net/~deja-dup-hackers/deja-dup/24/view/head:/data/Makefile.am for example
[20:48] <charles> + the service.in
[20:48] <mterry> charles, yeah
[20:48] <mterry> charles, and the data/Makefile.am
[20:48] <mterry> which does the sed
[20:48] <mterry> charles, and spread the word to the rest of the indicator team  :)
[20:48] <charles> gotcha, thanks mterry
[20:48] <charles> now, back to the on/off button...
[20:49] <charles> ... I'm still not seeing that behavior, are you just mouse-clicking it to activate? any odd steps I need to follow to reproduce?
[20:49] <mterry> charles, mouse clicking.  I'm following the steps in http://bazaar.launchpad.net/~indicator-applet-developers/indicator-sync/trunk/view/head:/examples/README
[20:51] <charles> mterry: whoa, yep there it is
[20:51] <charles> that's new. I've done that dozens of times
[20:51] <jbicha> boy, I hate it when the gdm lockscreen crash/freezes :(
[20:52] <charles> whatever the reason, it's reproducible now. Thanks mterry :)
[20:52] <mterry> charles, awesome