[11:56] <jdstrand> cjwatson: hi! can you help explain something with http://people.canonical.com/~ubuntu-archive/component-mismatches.txt? so, 'kate' is rescuing kate-dbg even though I put kate in universe. kate is seeded, but it is in kubuntu (according to platform.quantal, ubuntu.quantal and kubuntu.quantal)
[11:56] <jdstrand> cjwatson: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/rdepends/ALL/kate simply says 'Extra seed'
[11:58] <infinity> jdstrand: You left the source in main for some reason?
[11:58] <jdstrand> cjwatson: I can say that a newer kate was uploaded and then I changed the override before it was built, but change-override still overrode the binaries that were already built
[11:59] <jdstrand> infinity: the source needs to be in main for katepart. I am trying to demote kate the binary so I can demote kde-runtime
[11:59] <jdstrand> but kate doesn't pull in kde-runtime during the build and certainly shouldn't pull in kate-dbg
[11:59] <infinity> jdstrand: -dbg rescuing comes from source packages, I suspect.
[12:00] <jdstrand> infinity: that seems... odd since the source package would have to depend on itself, no?
[12:00] <infinity> jdstrand: Eh?
[12:01] <jdstrand> I mean, the build of the kate source package produces kate-dbg (which I am also trying to demote)
[12:01] <infinity> Yes, the build of the source package produces the dbg, and the source package is in main, hence the debug wants to be in main.
[12:01] <infinity> Since the dbg generally (and definitely in this case) contains debug symbols for stuff in main.
[12:02] <jdstrand> that would explain what is happening, but is that valid?
[12:02] <infinity> More importantly, why does katepart need to be in main at all?
[12:02] <jdstrand> if a normal non-dbg package is in universe, it can depend on stuff in main
[12:03] <jdstrand> infinity: well, unravelling kde dependencies has proved... difficult
[12:03] <jdstrand> iirc, it is needed by something that is needed by kdelibs5
[12:04] <jdstrand> so I was doing baby steps
[12:04] <infinity> You mean kdelibs5-plugins, not kdelibs5
[12:04] <jdstrand> which actually ended up being pre-teen steps
[12:04] <infinity> And it's libkhtml5 and libkio5 pulling in the plugins.
[12:04] <infinity> As recommends.
[12:04] <infinity> That could be fixed.
[12:04] <jdstrand> infinity: well, what I mean is that the farther back I went the harder it became
[12:05] <jdstrand> that's fine, and I will probably try to do that
[12:05] <infinity> I suspect dropping both those recommends to suggests would fix it all.
[12:05] <jdstrand> *but*, shouldn't a dbg package be demotable when its corresponding source is in main?
[12:06] <infinity> Maybe.
[12:06] <jdstrand> that seems reasonable to me-- but I feel I may lack a deeper understanding
[12:06] <infinity> Well, in my world, -dbg packages shouldn't exist, but that's not going to happen. :P
[12:07] <jdstrand> heh
[12:07] <infinity> If they do exist, though, you do kinda expect your debug symbols to be available in the same component.
[12:07] <infinity> And if you want the debug symbols for katepart, you need kate-dbg.
[12:07] <jdstrand> I would say you would expect them to be in a component that must also be installed
[12:07] <jdstrand> a >= as opposed to a =
[12:08] <infinity> Erm.  Come again?
[12:08] <infinity> What component "must also be installed" with main?
[12:08] <jdstrand> source in universe and dbg in main, no. source in main dbg in universe, ok
[12:08] <infinity> There's main.  And, uhm.  Main.
[12:08] <infinity> Honestly, splitting binaries across main/universe is ridiculous anyway, and I can't wait for archive reorg to finish.
[12:08] <jdstrand> you can't run a system with only universe enabled
[12:08] <infinity> jdstrand: This has nothing to do with universe, katepart is in main.
[12:09] <infinity> jdstrand: Therefor, katepart's debug symbols should be in main.
[12:09] <infinity> jdstrand: katepart's debug symbols are in kate-dbg.
[12:09] <jdstrand> ok, so you are saying that kate-dbg provides the symbols for kate *and* katepart. I was thinking only kate, which was demoted
[12:09] <jdstrand> that makes more sense
[12:09] <infinity> Yeah, it's debug symbols for the whole source package.
[12:10] <jdstrand> *sigh*
[12:10] <jdstrand> I'll have to look farther up the chain then
[12:10]  * jdstrand fixes the mismatches for now
[12:10] <jdstrand> cjwatson: nm
[12:10] <jdstrand> infinity: thanks!
[12:11] <infinity> Anyhow, dropping those Recommends to Suggests (on the plugins) would solve the issue, let kate fall out of main completely, and would have zero negative impact on kubuntu, since kde-runtime has a hard dep on kdelibs5-plugins anyway.
[12:12] <jdstrand> infinity: fyi, seems the report should have said 'Rescued from katepart' rather than 'Rescued from kate', but, meh)
[12:12] <infinity> jdstrand: No, cause it's rescued from the source package.
[12:12] <infinity> jdstrand: It's a bit hard to decipher when the source produces a binary by that name, I suppose, but once you've seen it a few times, you know what's up.
[12:12] <infinity> jdstrand: "rescued" are always a source->binary relationship.
[12:13] <infinity> jdstrand: As in "this source is in main for other reasons, so we're pulling in its debug, docs, whatever"
[12:13] <jdstrand> 'Rescued from kate:src'? anyhoo, not something I'm going fix and now that I know I don't need it fixed
[12:14]  * jdstrand did not know "rescued" are always a source->binary relationship before now, but takes note
[12:14] <jdstrand> infinity: again, thanks
[12:14] <infinity> In almost all cases, it's doing the right thing.  In this weird corner case, I can see how an override of some sort might be nice, but...
[12:14] <infinity> Dropping the Recommends is a bigger win anyway.
[12:14] <infinity> So, let's eat some buildd time and just do that.
[12:14] <infinity> It punts a bunch more k* stuff out of main.
[12:15] <jdstrand> yes, I wanted to do that. I got a ton of stuff out yesterday due to an unneeded dep on poxml in the installation-guide
[12:15] <infinity> Honestly, I think the only thing the main/universe split has had a positive effect on is teaching us what "recommends" *really* means.
[12:16] <infinity> See libwebkit->gst* as another fine example.
[12:16] <jdstrand> heh
[12:16] <infinity> People using Recommends to pull in everything under the sun are generally wrong.
[12:16] <infinity> And a library recommening plugins (which is the case with kde4libs here), is about as silly as python or perl recommending all their extensions.
[12:17] <infinity> No point having plugins, if you tell people they always want them installed. :P
[13:03] <jibel> Quantal Wubi images contains Precise since last Tuesday
[13:03] <jibel> bug 1031961
[13:03] <ubot2> Launchpad bug 1031961 in wubi "install LTS instead of Quantal starting from build 20120731.2" [Critical,Confirmed] https://launchpad.net/bugs/1031961
[13:05] <infinity> jibel: As in, wubi.exe is downloading from a precise path, or it's downloading from a quantal path, but the rootfs is actually precise?
[13:06] <jibel> infinity, it downloads the right image for Quantal eg http://cdimage.ubuntu.com/wubi/current/amd64.tar.xz but the content of the disk image is Precise
[13:06] <infinity> Oh, hrm.
[13:06] <infinity> I think I see the bit to blame.
[13:10] <infinity> Actually, wait.  What's the path used for precise?
[13:12] <jibel> infinity, there is none apparently. It should be http://cdimage.ubuntu.com/wubi/precise/ isn't it ?
[13:12] <infinity> It probably should be, yes.  That's the problem. :P
[13:12] <infinity> Looking into it.
[13:18] <infinity> jibel: Should be fixed now.  I think I'll spin a precise and a quantal wubi to make sure.
[13:21] <infinity> jibel: Will you be around to quickly verify both quantal and precise are sane for me later?
[13:22] <infinity> jibel: (Well, precise might fail due to the subirectory, actually, if precise's wubi.exe doesn't know to look there... But you can at least verify for me that quantal is still quantal after I do a precise build)
[13:26] <jibel> infinity, I can check the content of the images, but cannot install with wubi. I'm in a sprint and don't have any windows machine with me.
[13:27] <jibel> infinity, but let me know when I can do the verification, I'll try to find a victim.
[13:28] <infinity> jibel: current/ should be quantal again.
[13:29] <jibel> infinity, ack
[13:29] <infinity> jibel: precise is re-spinning, and should, I hope, land in wubi/precise/current instead. :P
[13:30] <ScottK> jdstrand: Was polkit-kde-1 on the list of packages you were messing with (It's in c-m again)?
[13:31] <jdstrand> ScottK: it was, and I am still poking at fixing this stuff
[13:31] <ScottK> OK.  I'll leave it be then.
[13:31] <jdstrand> yikes, the new kde upload undid a lot of my work
[13:32] <jdstrand> well, I'll try to sort it
[13:33] <infinity> Oh, FFS, the world is uninstallable due to a libexttextcat SOVER transition that breaks due to a -data package dependency.
[13:33] <infinity> And by "the world", I mean libreoffice.
[13:37] <ScottK> jdstrand: I'd suggest coordinating with Riddell  on it (I'm focused on a precise point release ATM).
[13:37] <jdstrand> I'm trying to do non-invasive stuff with no impact
[13:37] <Riddell> what what?
[13:38] <jdstrand> I will most certainly do so if I am doing crazy stuff
[13:38] <jdstrand> Riddell: I've been fiddling with overrides is all
[13:39] <jdstrand> if I can't manage non-intrusive changes, I'll put stuff back
[13:44] <skaet> ev, ping?
[13:51] <skaet> Riddell,   can you check that the Kubuntu images for Precise 12.04.1 are the expected ones showing up on the iso tracker now?
[13:52]  * Riddell looks
[13:53] <Riddell> skaet: yes I agree
[13:53] <skaet> Thanks Riddell,    will you be testing contact point this time around?
[13:54] <Riddell> skaet: yep can do
[13:57] <skaet> Riddell, coolio.   :)     When can we get a preliminary testing pass set of results to confirm no "egg on face" type of issues have cropped up with them?    Don't want to be respinning after final freeze, if at all possible.
[13:57] <infinity> Feh, so I guess I'm going to upload a new libreoffice.
[13:58] <infinity> At least I have the bandwidth for it.
[13:58] <infinity> But do I test build first or not.  Hrm.
[14:15] <Riddell> skaet: when are you wanting them?  is there an expected release day?
[14:40] <tseliot> can anybody reject cedarview-drm-drivers (in precise-proposed) please?
[14:41] <smartboyhw> How to?
[14:41] <tseliot> only if you're an archive admin ;)
[14:42] <smartboyhw> No, I
[14:42] <smartboyhw> am not
[14:42] <skaet> Riddell,  initial set of test runs to make sure no surprises in the manditory tests this next week would be good, as well as checking/updates to images size.   Final freeze (and ideally last set of images will be on  8/16,   release on 8/23)
[14:42] <smartboyhw> I am responsible for QA...
[14:42] <infinity> tseliot: With pleasure.
[14:42] <tseliot> infinity: thanks
[14:42] <infinity> tseliot: What did you break this time? :P
[14:43] <tseliot> infinity: there was a leftover which prevented the package from calling update-grub-gfxpayload. Nothing fancy, really ;)
[14:43] <Riddell> skaet: oh no rush then, shouldn't be a problem
[14:44] <infinity> tseliot: Kay.  Also, -vaapi-driver didn't get uploaded to match the new snapshot of drm and graphics.  Is that an issue?
[14:44] <tseliot> infinity: let me check with janimo
[14:45] <infinity> tseliot: https://launchpad.net/ubuntu/precise/+queue?queue_state=0 to see the current state of affairs.
[14:46] <tseliot> infinity: janimo says there were no changes for the vaapi package
[14:46] <infinity> jibel: Hrm, I'm undecided if those builds should go in /wubi/precise or /precise/wubi.  They're in the latter for now, though.
[14:46] <janimo> infinity, I had no idea there was an old cedarview-graphics package in NEW too
[14:47] <infinity> janimo: Well, there isn't anymore. ;)
[14:47] <janimo> infinity, otoh the vaapi package is that one from june
[14:47] <tseliot> infinity: I've just re-uploaded cedarview-drm-drivers
[14:47] <janimo> infinity, I wish there was no graphics there anymore :D
[14:48] <infinity> janimo: Yes, hence why I asked, since all the other June snapshots got updated to a July one, but not poor vaapi.
[14:48] <janimo> infinity, it is due to that not needing an update. Intel does not update all 3 components every drop
[14:48] <jibel> infinity, depends if wubi is considered a flavor or a variant of Ubuntu
[14:49] <janimo> so it is slightly more confusing but otherwise indep like other X/vaapi drivers
[14:49] <infinity> jibel: My gut is variant, and that /precise/wubi is correct.
[14:49] <infinity> jibel: Since it really is just an Ubuntu desktop filesystem and all.
[14:49]  * ogra_ considers wubi an insanity 
[14:50] <smartboyhw> I thought Wubi was great!
[14:50] <infinity> jibel: Anyhow, I suspect that the precise-proposed wubi.exe has no clue how to find it, no matter where I put it, so that's fun. :P
[14:51] <stgraber> infinity: /precise/wubi sounds good as it's technically part of the "ubuntu product" (same seeds and stuff as daily/daily-live/dvd/...)
[14:51] <infinity> jibel: One bridge at a time, though.  At least it's not overwriting the quantal image. :P
[14:51] <skaet> tseliot, cedarview-drm-drivers is a bit late,  hardware updates should have been uploaded couple of weeks ago.   What testing has been done?
[14:51] <jibel> infinity, agree, and it's an improvement :)
[14:51] <infinity> skaet: They've been uploaded repeatedly, and gone through a fair bit of NEW review.
[14:52] <tseliot> skaet: yes, I applied the changes suggested by slangasek and re-uploaded
[14:52] <skaet> infinity, tseliot - thanks.
[15:01] <janimo> skaet, same with the other cedarview packages
[15:01] <janimo> uploaded before July the 19th :)
[15:01] <janimo> the testing was mostly done in HWE/OEM
[15:03] <skaet> thanks janimo :)
[15:04] <janimo> skaet, np :)
[16:06] <infinity> Oh, crap, I didn't notice Sweetshark had targetted that libreoffice to quantal-proposed until just now. :/
[16:07] <infinity> Which means we get to wait for all arches before I can unbreak x86.
[16:07] <infinity> *sigh*
[16:08] <infinity> I suspect that's less than ideal.  Maybe I should re-upload to -release.
[16:08] <micahg> infinity: well, the issue is that libextttextcat should've gone to -proposed and not broken the world
[16:09] <infinity> micahg: That's nice, but less helpful. :P
[16:10] <micahg> infinity: maybe once x86 is finished, copy to -release and kill all the remaining -proposed builds
[16:11] <infinity> It's only an hour in, which is about the turnaround I'd have for copying to -release anyway.
[16:12] <micahg> infinity: right, but at least you'd have i386/amd64 not skewed
[16:12] <infinity> micahg: Yeah, but I can get that by just reuploading.
[16:12] <infinity> micahg: In the same amount of time.
[16:13] <infinity> And without manual intervention.
[16:13] <micahg> infinity: no guarantees on it
[16:13] <infinity> micahg: No guarantees on what?
[16:14] <micahg> arch synchronization between amd64/i386 w/out using proposed
[16:14] <infinity> It doesn't matter, it's all uninstallable anyway.
[16:14] <micahg> hrm, that's a good point
[16:20] <micahg> infinity: I'd say go for it then :0
[18:33] <slangasek> infinity: have you communicated to Sweetshark about what went wrong here, so that he knows for next time?
[19:10] <infinity> slangasek: In which sense?  The mistargeting of the upload, or the uninstallability of the world?
[19:11] <infinity> slangasek: The former wasn't something wrong, per se, I should have checked before I sponsored it, and the latter was the fault of whomever synced libexttextcat, not Sweetshark.
[19:11]  * micahg brought up both issues in -desktop about 3 hours ago
[19:12] <slangasek> infinity: "should have checked before sponsored it" - sure, and Sweetshark also should have prepared it for the correct target :)
[19:12] <micahg> infinity: well, sweetshark promised that syncing libexttextcat wouldn't break anything :)
[19:13] <infinity> slangasek: He already had it prepped for "an eventual upload to proposed", I don't think he was aware of the urgent need for a library transition until I brought it up. :P
[19:13] <slangasek> k
[19:13] <infinity> micahg: Ahh, I only saw that seb128 synced it, we need a better blame mechanism. ;)
[19:13] <infinity> micahg: If it was on Sweetshark's say-so, I take it all back, blame the LibO maintainer! ;)
[19:13] <micahg> hehe
[19:14] <micahg> no, in the end, the responsibility is that of the uploader
[19:14] <infinity> (That said, most people do seem to be blissfully unaware of the lib/-data breakages that occur on SONAME transitions, since they're so used to libraries normally being able to soft-transition)
[19:15] <micahg> indeed, but I thought we had test infrastructure for this stuff :)
[19:15] <infinity> It's a lesson you tend to only need to learn once, mind you.
[19:15] <seb128> we have?
[19:15] <micahg> seb128: couldn't the test lab be set up to test newer versions of dependencies?
[19:15] <seb128> dunno
[19:16] <seb128> you say we have, which is different from "coudn't ...3
[19:16] <micahg> right, I keep mixing reality and fantasy for some reason :-/
[19:16] <micahg> well, we have the infrastructure, it's just not configured to do it yet AIUI
[19:17] <seb128> same difference, there is no easy way to check that
[19:26] <stgraber> bdmurray: heya. sysvinit just reached 7 days in -proposed and as far as I'm concerned is good to go to -updates, when copying, please remember to pull lxc at the same time
[19:27] <stgraber> bdmurray: lxc is marked as 1 day old as the SRU period was reset after another fix was added. Accepting sysvinit without lxc would break containers. The extra lxc fix is trivial and has been verified, so skipping the validation period is fine.
[19:28] <slangasek> stgraber: are there appropriate Breaks: between the packages, so that the upgrade is guaranteed to happen in sync on the user's system too?
[19:34] <stgraber> slangasek: nope and that wouldn't have worked in this case as the problem is when the old lxc debootstraps a container with the new sysvinit
[19:35] <slangasek> ok
[19:49] <bdrung> vlc is in -proposed since eight days without someone reporting a regression (lp: #1025713). is it time to get it into -security/-updates? Not all bugs are verified, but vlc has a preliminary MRE
[19:53] <seb128> bdrung, MRE doesn't give you an exception of getting bugs verified
[19:53] <seb128> bdrung, it just means the SRU will be accetped
[19:53] <seb128> bdrung, once accepted it needs to follow the rules, all bugs need to be verified
[20:04] <bdrung> seb128: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions says "For MRE packages only, it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream, and it is not necessarily to manually independently verify them."
[20:05] <bdrung> and "When the preceding steps have been done, the headline bug (only) should be marked verification-done "
[20:05] <seb128> bdrung, hum, ok, that's not my experience, I guess the SRU team needs to coment
[20:07] <slangasek> seb128, bdrung: actually, that's *exactly* what an MRE gives you...
[20:08] <slangasek> you don't need per-bug verification if there's already been upstream validation - the latter being a prerequisite for an MRE
[20:08] <slangasek> the problem is our process doesn't flag MRE packages in a useful way :)
[20:08] <seb128> slangasek, hum ok, so SRU team has been pickier then should have with GNOME SRUs
[20:09] <slangasek> seb128: perhaps it would help to reference the MRE in the bugs referenced in the SRU changelog
[20:09] <seb128> slangasek, noted
[20:10] <slangasek> stgraber: did jodh talk to you about having a fix for bug #980917 now?
[20:10] <ubot2> Launchpad bug 980917 in upstart "Failed to create pty - disabling logging for job" [Medium,Triaged] https://launchpad.net/bugs/980917
[20:11] <slangasek> stgraber, seb128: we're past the freeze deadline; would you want this upstart change to go into .1 still?
[20:11] <stgraber> slangasek: yes, he did. He apparently got stuck in a UDD mess and was still trying to get something uploadable.
[20:11] <slangasek> (personally, I'm not sure it's worth it... upstart has never worked well without an initramfs so it's not really a regression vs. 10.04, so I don't see a reason to bend the rules wrt the freeze)
[20:12] <stgraber> slangasek: there's technically still 50min to go before the freeze, but I don't consider this critical to get in the point release as it's not affecting a (well) supported setup
[20:12] <slangasek> stgraber: jodh is past EOD and the fix is still being iterated, I'm not going to rush this :)
[20:12] <stgraber> so having it land in -proposed once it's unfrozen would be good enough for me
[20:13]  * slangasek nods
[20:20] <bdmurray> stgraber: is there anything special about resolvconf in -proposed?
[20:21] <stgraber> bdmurray: nope. It was verification-failed and I made it verification-done a few minutes ago as the fix technically works, just not for all the cases I thought it'd
[21:32] <ScottK> Is the "stable/release team" different than ubuntu-release?
[21:34] <bdrung> skaet: are unseeded package affected by the 12.04.1 preparation?
[21:35] <skaet> ScottK,  yes,  couple of members on stable release team that aren't in release team and visa versa.
[21:36] <ScottK> OK.  Who are the stable release team?
[21:36] <skaet> https://launchpad.net/~ubuntu-sru
[21:38] <ScottK> OK.  Then the terminology threw me.
[21:38] <skaet> bdrung,  we'll be trying to ratchet down the rate of change while we stabilize, so case by case for the unseeded packages.   Discuss in this channel with the SRU team if there's a compelling reason a fix can't wait.
[21:39] <ScottK> skaet: Does having stuff in queue, but not accepted hurt anything?
[21:39] <skaet> ScottK,  sorry,  probably should have added "Updates" in there, now that I'm looking at the definition.
[21:40] <skaet> ScottK,  doesn't hurt in principle,  key is keeping the accepts down unless very good reason.
[21:40] <ScottK> So I don't see why we should block uploads.
[21:41] <slangasek> skaet: why would we care about the rate of change of unseeded packages? I would expect these to be processed as normal since they have no impact on the .1 images
[21:41] <bdrung> skaet: i have nothing urgent. is it better to wait uploading stuff to -proposed or will it just be hold back until after the release of 12.04.1?
[21:41] <slangasek> bdrung: please keep uploading
[21:41] <bdrung> thanks
[21:42] <bdrung> then i have to excuse to debug wxwidgets
[21:42] <skaet> ScottK,  slangasek,  yes,  you're correct.
[21:46] <micahg> skaet: just an FYI, I'll probably push the webkit from -proposed to -security/-updates on Monday
[21:47] <stgraber> bdrung: wxwidges is seeded I believe, so yeah, upload what you want, but if it's seeded it won't be accepted into -proposed until we start building images from -updates
[21:48] <skaet> micahg,  ok.  thanks for the head's up.
[21:48] <micahg> umm, it just says Desktop Infrastructure Freeze on the interlock page, not seeded freeze...
[21:48] <bdmurray> how does the freeze affect reviewing what's in the precise queue?
[21:49] <bdrung> stgraber: right, it's seeded on kubuntu. wow, even vlc is seeded. i need to be careful.
[21:50] <slangasek> bdmurray: I had understood that we're not supposed to accept seeded packages into precise-proposed unless they're targeted for .1 and discussed here first
[21:50] <micahg> would be nice if seeded-in-ubuntu worked for LTS releases as well :)
[21:50] <slangasek> however, if 'stable/release team' == ~ubuntu-sru, apparently we just talk to ourselves ;)
[21:50] <ScottK> skaet and stgraber: I'd suggest making an exception for the mythtv SRU that's about to land.
[21:50] <bdrung> micahg: why does seeded-in-ubuntu does not work for LTS?
[21:51] <stgraber> ScottK: yeah, we have a bug for that, but it needs an MRE from the TB first (e-mail was sent to the list)
[21:51] <micahg> bdrung: it only works for the dev release ATM AIUI
[21:51] <bdmurray> slangasek: what about ones uploaded before the freeze?
[21:51] <stgraber> bdmurray: anything uploaded before 21:00 UTC today should be processed as normal
[21:51] <stgraber> bdmurray: anything uploaded after 21:00 UTC needs an exception
[21:52] <bdmurray> okay great so slangasek will approve my update-manager tomorrow
[21:54] <slangasek> or I could look at it now
[21:55] <ScottK> bdrung: I don't think wx is really seeded.  It's in Universe so it can't be in a Kubuntu seed for precise.
[21:56] <bdrung> ScottK: seeded-in-ubuntu wxwidgets2.8
[21:56] <stgraber> ScottK: it's seeded in edubuntu
[21:57] <bdrung> and ubuntustudio
[21:57] <ScottK> bdrung: Clearly it's at least partially incorrect because it's not seeded in Kubuntu in precise.
[21:58] <micahg> as I said, it's only for the dev release
[21:58] <ScottK> It would be nice if one could specify what release to use for seeded-in-ubuntu.
[21:58] <ScottK> OK.
[21:58] <micahg> tumbleweed: ^^
[21:58]  * bdrung pokes tumbleweed.
[21:59] <micahg> anyways, it's only supported in kubuntu, so that's not on an image
[21:59] <micahg> in quantal even that is
[22:01] <micahg> awesome, binary NEW with no relevant changelog..../me wonders if it's that pocket bug (looks like it)