[01:46] <StevenK> xnox: I'll look at mpd after work.
[01:47] <xnox> StevenK: thanks a lot! =)
[04:23] <orbisvicis> per apt-cache policy apt seems to be ignoring my /etc/apt/preferences file w.r.t the priority of my local repository
[05:13] <orbisvicis> it was a quoting problem, ftr
[05:58] <pitti> Good morning
[06:33] <dholbach> good morning
[06:33] <pitti> hey dholbach, good morning! wie gehts?
[06:34] <dholbach> hey pitti - sehr gut - wie geht's Dir?
[06:34] <pitti> dholbach: prima, danke!
[07:06] <dholbach> Did anyone see anything like "Failed to create secure directory (/run/user/1000/pulse): Permission denied" on saucy recently?
[07:17] <pitti> dholbach: currently being discussed in bug 1197395
[07:17] <dholbach> ah, super
[07:17] <dholbach> thanks
[08:39] <pitti> infinity: do you have a minute for an SRU review? (bug 1184262, systemd-shim for saucy-proposed); it's causing suspend breakage for way too many people :/
[08:41] <pitti> brainwash: ^ FYI
[11:27] <pitti> bdmurray: ^ do you have time today to process the systemd-shim saucy SRU review?
[12:52] <doko> jamespage, maven ping
[12:54] <Laney> doko: did you see my gcc-4.8 ping yesterday?
[12:55] <doko> tjaalton, instead of using an old MIR, could you use a new one for the samba deps? ldb, faketime, libparse-yapp-perl ? (or maybe zul, jamespage)
[12:55] <doko> Laney, yes, is this urgent?
[12:55] <Laney> not as long as it doesn't migrate
[13:02] <jamespage> infinity, are you OK for me to submit that atomic linking fix back upstream for openvswitch?
[13:02] <jamespage> just sweeping up patches
[13:06] <tjaalton> doko: ok, I'll file one for ldb for starters..
[13:06] <doko> tjaalton, please open tasks for the others too
[13:06] <jamespage> tjaalton, please can you check in with zul - he's being doing the merge and mir stuff for samba
[13:06] <jamespage> not sure exactly how far he's got as yet
[13:08] <tjaalton> jamespage: there was no MIR for ldb at least
[13:09] <tjaalton> faketime has bug 1250102
[13:10] <tjaalton> subscribed ubuntu-mir
[13:33] <tjaalton> zul: I've filed a MIR for libparse-yapp-perl too https://bugs.launchpad.net/bugs/1250466
[13:33] <tjaalton> doko: ^ that should be all of them
[13:33] <tjaalton> ldb is bug 1250463
[13:33] <doko> tjaalton, thanks
[13:33] <zul> tjaalton:  thanks
[13:54] <zul> how do you get something on the blacklist for merges.ubuntu.com?
[13:57] <cjwatson> zul: ask an archive admin to sync-blacklist it, but blacklisting isn't necessarily the right answer
[13:57] <cjwatson> zul: what in particular are you referring to?
[13:58] <zul> cjwatson:  i was looking at the list and we dont merge any of the openstack packaging from debian (so things like ceilometer and python-cinderclient, etc)
[13:58] <cjwatson> zul: That usually works out being a mistake in the long run
[13:59] <cjwatson> Usually when I run across that it's accompanied by swearing at the way Debian packaging improvements haven't been carried over into Ubuntu
[13:59] <cjwatson> So I'm pretty reluctant to entrench it
[14:00] <zul> cjwatson:  right but alot of the openstack debian packaging uses debconf which we dont consider an improvement and often broken
[14:00] <cjwatson> That doesn't mean other aspects aren't worth merging
[14:00] <zul> cjwatson:  sure
[14:00] <tseliot> stgraber: hi, can you have a look at bug #1250449 please? (new nvidia packages for trusty)
[14:00] <cjwatson> In particular Python module packages that are only maintained in Ubuntu usually end up being worse off IME
[14:05] <zul> cjwatson:  with regards to the merging  openstack packaging from debian we are often ahead so why dont they merge from us since the "packaging" style of the debian maintainer is not compatible with the stuff that we need to do
[14:07] <cjwatson> you're reasonably reliably ahead as long as the only metric you look at is the upstream version number
[14:08] <cjwatson> anyway, feel free to persuade some other archive admin, I'm not generally happy with blacklisting for this reason
[14:09] <jamespage> cjwatson, fortunately we also take into account peer review on every packaging commit and continual CI of packaging and deployment against upstream trunk and stable branches as well
[14:10] <cjwatson> like I say, I'm not going to agree on this, but you can try somebody else if you like :)
[14:10] <mitya57> zul: upstream OpenStack maintainer is usually friendly to Ubuntu and can even merge some Ubuntu-specific changes back, i.e. http://packages.qa.debian.org/b/blktap-dkms/news/20130322T121730Z.html
[14:10] <xnox> to me it seemed that debian is fairly actively up to date. But e.g. we packaged rc for release, and debian packaged final only.
[14:10] <cjwatson> I'm generally of the opinion that we should blacklist as little as possible
[14:10] <cjwatson> and that many of the blacklists we have so far have turned out to be trouble later
[14:11] <jamespage> cjwatson, fine - tbh is fairly moot anyway - by the time we get to first milestone for icehouse stuff won't appear on merges.u.c anyway
[14:11] <cjwatson> mainly because they tend to be maintenance-invisible
[14:12] <cjwatson> it's not a lack of review on the packaging changes that you *do* have that concerns me about this in general; it's invisibility of the patches you don't have that Debian does
[14:12] <cjwatson> and a general disdain for Debian
[14:12] <cjwatson> if they're doing it wrong, persuade them otherwise :)
[14:12] <jamespage> cjwatson, whoa - I never reflected that
[14:12] <jamespage> and I have tried :-(
[14:12] <cjwatson> it'll be better for everyone
[14:14] <cjwatson> there are packages I maintain where I disagree with the Debian maintainer about something; it just means a long-term delta, but not permanently ignoring them
[14:15] <jamespage> maybe a better way to have started this discussion would have been "we are divergent for a number of reasons on the openstack package set - whats the best way to manage this bearing in mind we will not ever quite sync up with debian"
[14:17] <cjwatson> my general opinion on that class of question is that it's perfectly OK to never quite sync up, but it's not clear to me that that means the long-term wise thing to do is to go it entirely alone
[14:18] <cjwatson> bearing in mind that long-term packaging divergence affects more than just one part of the archive; it can often have knock-on effects elsewhere with things like incomplete transitions
[14:18] <jamespage> cjwatson, we've been trying to figure out the best way to flow patches between Debian/Ubuntu but its really hard to track
[14:19] <jamespage> normally its a conversation in debian-openstack which works OK
[14:19] <cjwatson> frex some of the obsolete packages Debian has managed to remove entirely (e.g. python-central) are still stuck in Ubuntu because of a bunch of long-term-diverged or Ubuntu-local packages where people just haven't kept up
[14:19] <cjwatson> we lose out on archive-wide QA
[14:21] <cjwatson> in the case of Ubuntu, this is often particularly bad for packages that were once part of the Current Great Thing for a particular team but have since been abandoned, and this is really hard to track since by the nature of these things the teams who used to deal with them have now lost interest
[14:21] <cjwatson> unfortunately I see this pattern a fair bit
[14:21] <tjaalton> jamespage: infiltrate debian-openstack and maintain things there? :) /me runs..
[14:22] <jamespage> tjaalton, go look at the team membership list on alioth :-)
[14:22] <jamespage> like I said its hard to track....
[14:22] <tjaalton> can't, it's down :)
[14:23] <jamespage> tjaalton, forgot
[14:24] <jamespage> cjwatson, I can think of a few examples of that behaviour - yes
[14:35] <jamespage> doko, libjaxen fixed up to avoid maven - looking at testng next
[14:45] <jamespage> doko, think I can get rid of the testng requirement as well
[14:45] <jamespage> maybe
[14:50] <jamespage> doko, OK - once my upload of libhamcrest-java goes through testng can be demoted to universe
[14:50] <doko> \o/
[14:51]  * jamespage dodges the maven bullet again
[14:51] <jamespage> doko, it was referred to in one example that neither ships or is complied during package build...
[15:12] <infinity> jamespage: Woo!
[15:39] <xnox> Hm... are we going to have pypy in main =/
[15:42] <mitya57> For what?
[15:42] <seb128> dobey, hey, could you have a look to bug #1227277? that one seems like it might be a bug in s-c and not in gnome-menus/webkit
[15:43] <jamespage> infinity, Woo! == yes please go ahead?
[15:49] <doko> jamespage, zul: please can you subscribe to ldb and libparse-yapp-perl (samba deps)?
[15:49] <jamespage> doko, ack
[15:50] <zul> doko:  done
[15:50] <doko> thanks, promoting
[15:50] <zul> doko:  cool thanks
[15:51] <jamespage> doko, done
[15:55] <doko> barry, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg, could you look at the python related component mismatches? e.g. pypy shows up for simplejson again
[15:55] <barry> doko: sure.  might be a while
[16:00] <doko> seb128, didrocks: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  rythmbox recommends ephiphany-browser. wanted?
[16:01] <seb128> doko, no
[16:01] <seb128> Laney, ^
[16:01] <didrocks> I don't think it was expected :)
[16:01] <seb128> Laney did the rb update I think
[16:01] <didrocks> Laney: you wanted a new browser to please mdeslaur? :)
[16:01] <Laney> arm64
[16:02] <doko> ahh, yes, arm64 doesn't have another one
[16:02] <mdeslaur> argh! :)
[16:03] <xnox> doko: can we make w3m provide x-www-browser on arm64?! =)
[16:03] <seb128> Laney, why does rb need to recommend a browser?
[16:03] <xnox> seb128: to open u1 music store?
[16:04] <mdeslaur> there's no way epiphany is going to main
[16:04] <Laney> nobody's askign it to
[16:04] <seb128> xnox, isn't that a "try to activate an url, how the url is handled is up to the system"?
[16:04] <Laney> I assume it's from the plugin
[16:05] <xnox> i wonder if dropping to suggests will just work. Since anybody that has rhythmbox installed is likely to have a graphical web-browser, and if they don't, they are probably installing everything with no-recommends and no-suggests anyway.
[16:06] <Laney> Just ignore it
[16:08] <seb128> Laney, well, if it's creating noise on component mistmatch it's still annoying?
[16:09] <cjwatson> Best fix is to port firefox; until then it's a known false positive and you should just ignore it really
[16:09] <cjwatson> No point getting exercised over it
[16:10] <seb128> well, downgrading to a Suggests would make sense, I'm not sure an application needs to recommends a webbrowser just because one of its plugin has an url handler
[16:10] <Laney> It is weird for a mozilla plugin to recommend epiphany-browser, mind you
[16:10] <seb128> but yeah, not an important topic
[16:10] <Laney> it's not a url handler
[16:10] <cjwatson> seb128: if it weren't rhythmbox it would probably be something else; I don't think there's any point in focusing on rb here
[16:11] <seb128> right
[16:15] <mitya57> ScottK: by the way, I'm wondering if you volunteer to re-upload qtsensors with fixed arm symbols, or should I put it on sponsoring queue?
[16:16] <ScottK> I'll take care of it.
[16:16] <mitya57> Thanks (bonus points for uploading that to Debian as well)
[16:17]  * ScottK didn't get home from working until 3AM yesterday (which was only 8 hours ago here), so I'm a bit behind today.
[16:17] <ScottK> It's in the Debian Qt-KDE repo, right?
[16:17] <mitya57> ... which is down
[16:17] <ScottK> Good point.
[16:17] <ScottK> I'll ask lisandro.
[16:19]  * mitya57 didn't ask lisandro because lisandro is already busy uploading a bunch of mitya57's qt5.2
[16:19] <ScottK> Right, I just don't want to step into what he's doing without discussing.
[16:20] <mitya57> Ok.
[16:29] <hallyn_> infinity: fwiw, qemu package with qemu-arm64-static is in ppa:serge-hallyn/virt.  (didn't manually add -lgpg-error so hadn't expectd it to build)  not sure what to test with.
[16:31] <xnox> hallyn_: libnih + upstart have in excess of 6k+ tests. Also eglibc test-suite =)
[16:36] <hallyn_> xnox: do we have arm64 builds of those?  id'd need to build a chroot to start i assume
[16:37] <xnox> hallyn_: yes, we do have arm64 of those. we have most of main build.
[16:38] <xnox> hallyn_: you can do $ mk-sbuild --arch arm64
[16:38] <hallyn_> are you sure?  most builds i've seen just fail
[16:38] <hallyn_> but ok, i'll see, thx
[16:39] <xnox> hallyn_: if you have qemu-arm64-static, it should be able to bootstrap arm64 chroot, with qemu-arm64-static. After that builds are just $ sbuild --arch arm64 *.dsc
[16:39] <xnox> hallyn_: our arm64 port rocks - https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes -  94% of the binary packages in the "main" component are available, and 69% of the binary packages in the archive as a whole.
[16:40] <xnox> hallyn_: sure a few things needed to be retried a few times, but overall it mostly builds.
[16:40] <hallyn_> hm
[16:40] <xnox> in trusty it's even more.
[16:55] <Laney> hrm, is gcc-4.7 problematic on arm64? https://launchpadlibrarian.net/156422079/buildlog_ubuntu-trusty-arm64.webkitgtk_2.2.1-2ubuntu1_FAILEDTOBUILD.txt.gz
[17:11] <infinity> jamespage: The woo was for dodging the maven bullet.
[17:11] <infinity> hallyn_: Grabbing the ubuntu-core tarball, untarring it, copying qemu-arm64-static to usr/sbin and chrooting in should work.
[17:12] <infinity> Laney: AFAIK, it should work.  Would be hard for it to have been built if it doesn't work at all.
[17:13] <hallyn_> infinity: will try that, thanks
[17:13] <Laney> Mmm.
[17:13] <robru> bschaefer, ping? just curious about the status of unity7 tests from friday (forgot to follow up with you then)
[17:13] <infinity> Laney: autoconf's "compiler can't create executables, HALP" message is generally useless without a config.log, where you'll see that it's probably just exiting non-0 due to a missing include or -l or something.
[17:13] <infinity> Laney: I can try to look at it between now and when I have a plane to catch.  Just headless chickening a bit this morning.
[17:13] <Laney> infinity: If you like. I'm a bit loathe to do blind uploads of webkit
[17:13] <infinity> Laney: That said, why is webkit building with gcc-4.7?
[17:13] <bschaefer> robru, hmm which tests? I don't seem to remember...
[17:14] <Laney> infinity: It could be dropped, that came from Debian.
[17:14] <robru> bschaefer, yeah i don't remember either ;-) but didrocks says that just in general you were working towards eliminating some flaky tests and getting unity7 green.
[17:14] <robru> he asked me to follow up with you
[17:14] <Laney> Well, maybe could be dropped. They chose 4.7 to avoid 4.6, not to avoid 4.8.
[17:15] <bschaefer> robru, oo, yeah our goal for unity 7 is get get all the AP tests working but its very hard to do, so far nothing new has happened
[17:15] <robru> bschaefer, oh ok. well maybe just ping me if you make any progress today. no worries.
[17:16] <bschaefer> robru, alright will do
[17:17] <robru> bschaefer, thanks
[17:17] <infinity> Laney: Well, if it works with 4.8 (or, rather, with the default gcc, which is currently 4.8), that would be better than hardcoding it, and doko will love you forever.
[17:18] <infinity> Laney: I'm not one to talk, though, I hardcode in glibc, and sort of have to, so I'm arguably the worst offender for keeping old compilers around. :/
[17:18] <infinity> Laney: Anyhow, when I get my bearings this morning, I'll do a quick test of webkitgtk on arm64 for you and see what config.log is whining about.
[17:18] <Laney> Ta
[17:19] <Laney> Feel free to make the 4.8 (default) change too if that works
[17:19] <Laney> See my previous comment about blind uploads. :P
[17:20] <mitya57> ScottK: thanks for qtsensors!
[17:20] <ScottK> mitya57: YW.
[17:23] <jamespage> infinity, well that was definately a woo!
[17:27] <ScottK> mitya57: Want me to add you to uploaders too?
[17:28] <mitya57> Ah, please do.
[17:29] <ScottK> OK.  Will do.
[18:04] <infinity> Laney: Wait, webkitgtk is new source?
[18:04] <infinity> Laney: Does that have ancestry somewhere else?
[18:04] <Laney> It's a rename from webkit
[18:04] <infinity> Rename and a massive version bump...
[18:05] <Laney> haha, I didn't do any arithmetic on it
[18:05] <Laney> It includes new packages for the webkit 2 API
[18:07] <infinity> conftest.c:1:0: error: target system does not support the "stabs" debug format
[18:07] <infinity> Laney: ^-- That's your error.
[18:08] <Laney> Ta, that is actually probably my error
[18:08] <infinity> Laney: -g should work fine.
[18:08] <infinity> Laney: If the goal is to avoid large links on 32-bit platforms, arm64 is, I'm pretty sure, 64-bit. ;)
[18:09] <infinity> Laney: And I assume -g is the default for things that aren't in the two filter lists.
[18:09] <infinity> Laney: Also, we're not (yet) using EGL on arm64, so adding it to the glx/egl list with armel and armhf is probably also wrong.
[18:10] <infinity> Laney: We may switch that at some point, but right now, arm64 is built for standard GL (and the previous webkit was too)
[18:10] <infinity> Laney: So, basically, the two things you added to be clever in the merge are the two broken things. ;)
[18:10] <Laney> There's k-a there, so it's not just 32
[18:11] <Laney> I did ask if there was a way I could test build it. :P
[18:11] <Laney> But yeah, woe is me
[18:11] <infinity> Laney: My bet is that the addition of kfreebsd-amd64 to that list was a mistake/misunderstanding, but whatever.
[18:12] <infinity> Laney: if it were me, I'd probably just filter on DEB_HOST_ARCH_BITS and be done with it, but I also don't have a high carefactor here, if the current solution works.
[18:17] <Laney> I think it might have done bad things to the kfreebsd-amd64 buildd
[18:18] <Laney> There's a couple of buildlogs in which ld gets killed
[18:19] <infinity> Laney: That could just be the kfreebsd-amd64 being shit.  The solution there shouldn't be to neuter builds.  But, like I said, carefactor low.  If the current thing works, meh.
[18:19] <infinity> Laney: kfreebsd is actually becoming a usable and mature product, though, so I might start caring more very soon.
[18:20] <infinity> (Once I waste a month of my hobby/spare time to help Petr get all his glibc patches upstream, I'll be even more confident in that position)
[18:20] <Laney> Want to test build an upload removing my crap?
[18:20] <Laney> Could also use 4.8 too.
[18:33] <infinity> Laney: No need to switch compilers just yet.  We can investigate that another time.
[18:33] <infinity> Laney: I can kick off a test build, but it won't be done before I'm in the air.
[18:34] <Laney> Meh, can do it in the archive.
[18:34] <infinity> Laney: And then I have YYC->LHR->CBG before I'll be sort of around again.
[18:34] <Laney> Good ol' CBG
[19:01] <seb128> bdmurray, infinity, slangasek: is any of you planning to do some saucy SRU reviews soon? ;-) (we have some fixes for high ranked e.u.c issues in the queue, I'm trying to get thing moving so we keep tackling stuff on the report)
[19:03] <seb128> bdmurray, infinity, slangasek: indicator-application and telepathy-mission-control-5 are in this category (and should be straightforward to review) (lightdm would be nice as well but that's less trivial as an update)
[19:03] <bdmurray> seb128: I work on SRU stuff on Thursdays
[19:04] <seb128> bdmurray, do we have anyone active on other days?
[19:04] <seb128> bdmurray, thanks for the work you are putting on SRUs btw!
[19:05] <bdmurray> seb128: I thought I saw ScottK release some updates the other day and slangasek works on the queue on Fridays
[19:10] <infinity> seb128: I'll look at the queue in a second, just on the phone with an airline.
[19:10] <infinity> (Monday is my day, in theory, but I was off yesterday, so meh)
[19:11] <seb128> infinity, thanks, the telepathy/indicator ones should be trivial so I would appreciate if you could review/get them through
[19:16] <seb128> doh, stgraber just copied some SRUs over
[19:16] <Alan-1> Does anyone know how I can get a google api that is associated with a google PAGE (not a google personal profile)?
[19:16] <seb128> stgraber, can you copy ido as well? I just marked https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1246536 verification-done
[19:17] <seb128> stgraber, hud as well it you can ;-)
[19:18] <stgraber> seb128: finishing my current pass, hopefully the report will then update and I'll spot the other ones you just tested
[19:18] <seb128> stgraber, great, thanks ;-)
[19:19]  * seb128 battles e.u.c
[19:19]  * seb128 wishes that mvo and dobey would help for update-manager/software-center issues that are close from top-ing now
[19:20] <Laney> Grr, looks like arm64 is still busted (but likely to be fixed with the exp version, which we can probably sync)
[19:23] <ScottK> seb128: I do it when I have time, which is uneven, so I don't have a specific day.  I did do a bit yesterday.
[19:23] <infinity> Laney: That looks pretty spectacularly broken.
[19:24] <Laney> It totally is
[19:26] <seb128> ScottK, ok, thanks for the work ;-)
[19:27] <infinity> seb128: bug #1217086 is marked Fix Committed for trusty, is there a pending upload for that?
[19:29] <infinity> seb128: Oh, looks like ubuntu7 has it.  Nevermind.
[19:31] <seb128> infinity, ;-)
[19:34] <stgraber> seb128: ido and hud released
[19:34] <seb128> stgraber, infinity: thanks!
[19:38] <arrun> Hello guys, I wanted to know how to create a language package and apply on the box?
[19:39] <infinity> seb128: bug #1238149 has a note that it's artificially failed until ido is released.  Does that mean we can release gtk now?
[19:56] <seb128> infinity, yeah, see the comment I added at the same time you were pinging on IRC ;-)
[19:57] <stgraber> infinity: I just noticed that (as I was looking at the next gtk+3.0) and released it already
[19:58] <infinity> stgraber: Heh.  Awesome.  I'll close those browser tabs, then. :P
[19:58] <arrun> Hello guys, I wanted to know how to create a language package and apply on the box?
[20:04] <stgraber> pitti: I'm confused by bug 1211514 and its saucy SRU, what's the status of all that?
[20:05] <stgraber> the bug status would suggest it's not fixed in trusty, but what's in the queue appears to be a backport of trusty, so I'm wondering whether that upload actually fixes the bug
[20:06] <stgraber> (also, it'd have been nice if we could have somehow avoided the massive autoconf diff in the SRU...)
[20:24] <NikTh> Hello everyone.
[20:25] <NikTh> If anyone knows, is it possible to build kernel 3.12 for precise and upload it to a PPA ?
[20:25] <arrun> Hello guys, I wanted to know how to create a language package and apply on the box?
[20:27] <NikTh> I tried to built it but, it failed due to dependencies problems in pbuilder. I assume it will fail in launchpad virtual builders too.
[20:37] <infinity> NikTh: You'll find that there's a delta between linux/3.11 in saucy and linux-lts-saucy/3.11 in precise.  I assume that same delta would need massaging and application to 3.12
[20:39] <NikTh> infinity: Thanks . I thought the same thing. Probably this would be applicable when linux-lts-trusty will be released, I presume.
[20:59] <ScottK> Laney: Any idea what's up with your lilpond SRU build for powerpc?
[21:29] <Laney> ScottK: Nope, mailed the upstream people who asked me to do the fix and they are looking into it
[21:44] <ScottK> Laney: Thanks.
[23:19] <sarnold> does anyone know more about the flood of "package <foo> failed to install/upgrade: package <foo> is already installed and configured" that we're getting these days?
[23:19] <sarnold> should I be assigning them all to apt? leave them at dpkg or whatever package was selected by the bug reporting tool?
[23:20] <ScottK> Got an example?
[23:21] <sarnold> ScottK: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1249757
[23:24] <ScottK> No idea.
[23:24] <ScottK> I vote slangasek most likely to know and be unable to resist looking.
[23:25] <ScottK> infinity would know, but he'd probably resist.
[23:26] <xnox> sarnold: looking and the dpkg log file attached it looks weird. user is manually installing nvidia-current, yet all the "needed" packages to be installed are already installed =/
[23:26] <ScottK> xnox: but it still shouldn't get that error.
[23:26] <xnox> sarnold: usually there is a bot that comes around and tells people to try something along the lines of $ dpkg --configure -a
[23:26] <sarnold> xnox: hrm. I wonder if some guide published recently has lead a lot of people astray..
[23:26] <ScottK> And he said this is one of a rash of errors.
[23:27] <ScottK> Even if you manually install  a package that's already installed, you shouldn't get that error.
[23:34] <slangasek> sarnold, ScottK: I suspect an aptdaemon bug
[23:34] <slangasek> bdmurray: ^^ have you noticed this uptick in 'is already installed and configured' bugs?
[23:34] <sarnold> slangasek: would it be helpful for me to re-assign the package for some of these bugs?
[23:34] <slangasek> sarnold: I'd say aptdaemon is the place to start
[23:41] <sarnold> slangasek, ScottK, xnox, thanks! :) I've moved a handful of recent bugs over to aptdaemon.
[23:46] <bdmurray> slangasek: yes, I think so
[23:46] <bdmurray> slangasek: I was looking at bug 1046856 somewhat recently
[23:47] <slangasek> bdmurray: can we pin it down to a version of some package? (aptdaemon?)