[01:34] <GTRsdk> Can program names be asked for in here?
[01:37] <GTRsdk> If so... What programs are required to make the Printing app work the way it does (with the click to find network printers, and easy setup)?
[05:13] <pitti> Good morning
[05:35] <pitti> @pilot in
[06:57] <dholbach> good morning
[06:58] <ion> morning
[07:11] <pitti> tkamppeter_: good morning
[07:11] <pitti> tkamppeter_: can you please also forward the libusb1.0 debdiffs to Debian BTS?
[07:12] <pitti> tkamppeter_: (bug 918774)
[07:13] <pitti> tkamppeter_: oh, these weren't your patches, nevermind; I'll forward them
[07:21] <dholbach> can somebody please reject https://code.launchpad.net/~ianrob1201/ubuntu/quantal/libmoosex-semiaffordanceaccessor-perl/typo-fix/+merge/122370?
[07:27] <pitti> dholbach: done
[07:27] <dholbach> thanks pitti
[07:31] <alkisg> pitti: hi, re: LP bug #1048207, the proposed patch works, but the script is indeed a bit unreadable wrt variables names, if you prefer I can rewrite it a bit so that it doesn't use temp files etc
[07:32] <pitti> alkisg: oh sorry, I mis-read it
[07:33] <pitti> alkisg: I'll apply it soon, thanks!
[07:33] <alkisg> Thank you too :)
[07:35] <alkisg> Btw, ubiquity-dm breaks the keyboard layout for all languages that support multiple keyboard layouts. That affects all live CDs, I've seen it reported under multiple packages in LP, but I didn't see anyone working on it. I can invest some time to troubleshoot it if someone knowledgable about ubiquity can point me to the right direction. LP bug #975803, comment 5
[07:36] <alkisg> If I "maybe-ubiquity" is omitted from the kernel command line, then the keyboard layout is fine, both in custom live CDs and in the official one
[07:38] <alkisg> That's pretty serious, as e.g. if someone wants to install ubuntu in greek now, he can't type english letters in the installer (username etc)
[08:51]  * dholbach hugs pitti
[08:51]  * pitti hugs dholbach back :)
[09:17] <cjwatson> pitti: heads-up on bug 1048211, breaking all images - if you'd be so kind
[09:18] <pitti> cjwatson: whoops, will do; sorry about that
[09:18] <cjwatson> thanks
[09:19] <cjwatson> perhaps we could get it into Ubuntu first without waiting for the sync process to catch up, and then we can respin images?
[09:19] <pitti> sure, I can upload a -6git1 or so
[09:19] <cjwatson> ta
[09:19] <pitti> I'll be done with my current sponsoring task in < 1 min, then will get to this
[09:27] <pitti> cjwatson: uploaded; I'll need to do two more fixes anyway (tests uncover some bugs in xfsprogs and reiserfsprogs), so I'll do a proper -5 soon
[09:27] <cjwatson> OK, thanks
[09:52] <pitti> @pilot out
[10:31] <brendand> does anyone know where the tool 'rendercheck' is packaged?
[10:31] <brendand> for precise preferably
[10:31] <pitti> x11-apps: /usr/bin/rendercheck
[10:31] <pitti> brendand: command-not-found is your friend? :-)
[10:32] <brendand> pitti - yeah, but i have x11-apps installed and when  i try to run rendercheck, command-not-found doesn't help me out
[10:32] <pitti> "dpkg -S rendercheck" then
[10:32] <brendand> nothing
[10:33] <pitti> that searches packages for installed files
[10:33] <pitti> then it might be new in quantal, perhaps
[10:33] <brendand> that's what i'm going to suspect
[10:35] <cjwatson> brendand: packages.ubuntu.com can do per-series file lookups
[10:37] <Laney> did we get all of the fontconfig warnings? anyone still getting them?
[10:37] <pitti> Laney: I just sponsored a patch for fonts-arphic-uming an hour or so ago; the bug still had one open task
[10:37]  * mlankhorst is back!
[10:37] <pitti> bug 1034928
[10:37] <Laney> pitti: yeah, I'm looking at that
[10:38] <pitti> for me they are gone, though
[10:38] <Laney> I see they're all closed, just making sure the bug had all of the required tasks
[10:38] <Laney> same
[10:38] <cjwatson> I'm seeing them from 25-wqy-zenhei, 90-fonts-baekmuk, and 90-fonts-unfonts-extra still, as well as *-arphic-uming
[10:39] <pitti> the last one should be fixed now
[10:41] <Laney> i'll add tasks for those first three, cheers
[10:50] <xnox> Laney: i thought unfonts-extra were fixed together with unfonts
[10:50] <Laney> maybe so
[10:50] <Laney> but maybe not if people are still seeing the messages
[10:51] <xnox> Laney: atk-bridge warning from gtk is annoying.....
[10:51] <Laney> hmm?
[10:52] <xnox> Laney: Gtk-Message: Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.
[10:53] <Laney> never seen that
[10:53] <Laney> what does it come from?
[10:54] <xnox> Laney: any gtk app. Close all nautilus windows & run `xdg-open ~' from terminal....
[10:54] <xnox> Laney: yeap unfonts-extra still not fixed, line 16 =(
[10:54] <Laney> nope
[10:54] <xnox> I wonder if I have a11y enabled then somehow for something and hence I get that.
[10:55] <xnox> Laney: google search suggests that I am not the only one with that message
[10:56] <Laney> you're never alone when it comes to warnings
[10:57]  * xnox rather wishes I was never alone when it comes to relationships..... *sigh*
[10:58] <cjwatson> cyphermox: I rebuilt tracker for something unrelated and got stuff like https://launchpadlibrarian.net/115371900/buildlog_ubuntu-quantal-i386.tracker_0.14.1-1ubuntu3_FAILEDTOBUILD.txt.gz - do you think you could fix it up?
[10:58] <Andy80> hi all!
[10:59] <Andy80> dholbach: hi! Why did you remove so precious informations from this page https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative ? Luckly there is the history available https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative?action=recall&rev=48 you completly removed all info about branching/committing/pushing etc... :(
[11:22] <mpt> ev, though we may not easily be able to calculate "If all updates were installed", we could calculate the distribution of "How many days out of date (if at all) is the package each error occurred in"
[11:22] <lifeless> ev: btw, wgrants fix has deployed, so it shold be a lot faster now.
[11:23] <ev> lifeless: indeed, caught that this morning. Thanks to the both of you!
[11:23] <ev> mpt: I'm not seeing how they're related
[11:24] <mpt> ev, it would be a rough approximation of how quickly people install updates (though it would assume that updates don't reduce the error rate, which is hopefully a bad assumption)
[11:33] <dholbach> Andy80, I wanted to have them in here http://developer.ubuntu.com/packaging/html/fixing-a-bug-example.html - we almost ran out of description typo bugs
[11:34] <dholbach> Andy80, the rest were in packages which are very likely to be removed
[11:34] <dholbach> (unless you are going to be fix typos in descriptions of packages which are in Debian)
[11:37] <dholbach> Andy80, ideally we'd have all the "here's how you work the tools" bits and general explanation in the packaging guide and just what is specific to the bug fix, like "fix the typo" on the wiki page
[11:37] <dholbach> so we don't duplicate too much
[12:26] <ev> mpt: sounds reasonably straightforward. Are you still going to send that email to -tech asking for more ideas, or are you settled on this?
[12:30] <mpt> ev, no, not settled at all
[12:30] <ev> okay
[12:30] <mpt> just thinking idly
[12:30] <ev> sure
[13:35] <cyphermox> cjwatson: sure, I'll take a look.
[13:35] <cjwatson> thanks
[13:42] <didrocks> can anyone mark https://code.launchpad.net/~bcurtiswx/ubuntu/precise/telepathy-glib/0.18.2-0ubuntu1/+merge/117176 as rejected? (was not against -proposed)
[13:43] <stgraber> didrocks: done
[13:44] <didrocks> stgraber: thanks :)
[13:53] <pitti> didrocks: it can't -- there is no -proposed version of telepathy-glib yet
[13:53] <pitti> UDD doesn't work like that for SRUs
[13:53] <pitti> didrocks: so for sponsoring you'd checkout the precise branch, do the merge, prepare/build source package, but NOT push
[13:53] <didrocks> ah, interesting… so it's a bootstrapping issue basically :)
[13:53] <didrocks> hum, I've already pushed TBH
[13:53] <pitti> and let the package importer sort it out
[13:54] <didrocks> ah you mean
[13:54] <pitti> didrocks: then perhaps please uncommit and push --overwrite
[13:54] <didrocks> not the branch
[13:54] <didrocks> yeah
[13:54] <didrocks> will do that I think
[13:54] <pitti> didrocks: yes, push to the precise branch, I mean
[13:54] <pitti> personally, I prefer simple debdiffs for SRU sponsoring any day..
[13:54] <cjwatson> Yeah, saves on thinking
[14:07] <micahg> well, saves on thinking only if there's a non UDD Vcs-Bzr
[14:07] <micahg> *there'a not a
[14:07] <cjwatson> Which chances are would point to the development series anyway
[14:07] <cjwatson> Not exclusively, but vast majority ...
[14:15] <cjwatson> Can anyone explain to me why bug 1028213 is on http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html ?  It doesn't have a rls-q-tracking tag (nor, I think, should it).
[14:16] <Laney> probably because of the milestone
[14:17] <Laney> or the quantal task
[14:18]  * xnox doko++
[14:18] <xnox> good upload.
[14:19] <xnox> doko: did you mean to have a comment on the second PRETTY_NAME as well?
[14:20] <Laney> which upload?
[14:20] <xnox> Laney: http://launchpadlibrarian.net/115385783/base-files_6.5ubuntu8_6.5ubuntu9.diff.gz
[14:20] <cjwatson> Laney: Seems silly for rls-q-tracking-bug-tasks to include things that aren't rls-q-tracking bug tasks.
[14:20] <cjwatson> bdmurray: ^- Do you know what's going on with the above?
[14:21] <xnox> cjwatson: I agree. I sometimes assign stuff to myself and target to quantal, but it does not mean it's rls-q-tracking at all.....
[14:21] <Laney> It's the workflow that Steve outlined some time ago
[14:22] <xnox> Laney: is there documentation about it? maybe I am doing it wrong.
[14:22] <Laney> there's no rls-q-tracking any more afaik
[14:22] <xnox> yeah there is....
[14:23] <doko> xnox, ohh, yes. do you want to fix it?
[14:23] <xnox> Laney: or is there -incomming & -wontfix => transition to => quantal-series + assignee without any rls-q- tags?
[14:23] <xnox> doko: ok.
[14:23] <cjwatson> ah, yeah, maybe I lost track
[14:24] <cjwatson> hm, rls-q-notfixing is kind of wrong though because I don't want to make (or seem like I'm making) that claim on behalf of YokoZar
[14:24] <Laney> I suppose you should remove the quantal task
[14:25] <cjwatson> can't untarget once it's been targeted
[14:25] <cjwatson> I don't think
[14:25] <xnox> doko: can the source file not be generated from lsb_release file?
[14:25]  * cjwatson tries on qastaging
[14:25] <Laney> I see a no entry button
[14:25] <Laney> what does that do?
[14:25] <Laney> I suppose it's a "-" actually
[14:25] <stgraber> you can untarget by clicking on the minus sign
[14:26] <cjwatson> that's what I was going to try
[14:26] <Laney> I assume that untargets, not that I can recall ever using it
[14:26] <xnox> I love how you can untarget "Ubuntu" and then there is simply a lingering task left.....
[14:26] <Laney> have you actually done that?
[14:27] <xnox> Laney: i believe so, maybe it's just the ajax rending....
[14:29] <stgraber> I used it a few times to remove specific series from bugs, yes
[14:41] <xnox> doko: done.
[14:42] <bdmurray> xnox: rls-q-incoming has one 'm'
[14:43] <xnox> ;-)
[14:43] <bdmurray> cjwatson: did you sort out the answer to rls-q-tracking?
[14:43] <cjwatson> Yeah
[14:43] <cjwatson> My misunderstanding
[14:51] <bdmurray> pitti: did you work on the software-properties drivers code at all?  bug 1028388
[14:53] <pitti> bdmurray: not really, that was cyphermox's work
[14:53] <pitti> cyphermox: ^ could you have a look please?
[14:53] <bdmurray> pitti: okay thanks
[14:53] <cyphermox> yeah I was looking at it
[14:53] <cyphermox> pitti: in fact it's didrocks now ;)
[14:54] <cyphermox> the model/vendor stuff is in UbuntuDrivers AFAICT though
[14:54] <cyphermox> still, I'm looking into it
[14:54] <cjwatson> hah, yeah, I was just looking at that bug
[14:54] <cyphermox> oops
[14:54] <didrocks> cyphermox: if you have some time for that, I'll appreciate, I'm supposed to be on the +1 team, but that with the unity team to track and the desktop team, that starts to be quite a lot :)
[14:54] <cjwatson> never mind, I didn't say so
[14:55] <cjwatson> UbuntuDrivers.detect documents that vendor and model are only set in that dictionary if values for them are known
[14:55] <cyphermox> didrocks: np, should be simple enough
[14:55] <cjwatson> so software-properties clearly needs to handle the case where they're absent
[14:55] <cjwatson> cyphermox: go ahead anyway, I have enough to do :)
[14:55] <cyphermox> cjwatson: ah, I was wondering if it wouldn't be best to make them "(unknown)" in UbuntuDrivers in those cases where it's not available
[14:56] <cjwatson> needs i18n though doesn't it?
[14:56] <pitti> I ratrher wouldn't
[14:56] <cyphermox> though that's not exactly pretty
[14:56] <pitti> u-d-common has no i18n
[14:56] <cjwatson> I figured that might reasonably be a frontend decision
[14:56] <cyphermox> ah!
[14:56] <cyphermox> yeah
[14:56] <pitti> I can set them to None if that helps
[14:56] <pitti> but either way you need to handle it
[14:56] <cjwatson> for instance some frontends might just leave them out
[14:56] <cyphermox> pitti: don't bother, we can do that in UI
[14:56] <cjwatson> pitti: can't see how it'd make much difference; at least this failure is obvious
[14:56] <pitti> but you can use results.get('vendor', _('Unknown')) in the UI
[14:57] <pitti> get() is really convenient for these cases
[14:57] <pitti> cjwatson: yeah, that's why I made it that way instead of None; just hides errors
[15:05] <cyphermox> pitti: weird, my system used to be detected as requiring an nvidia card, now it doesn't
[15:05] <cyphermox> s/card/driver/
[15:05] <pitti> cyphermox: can you pastebin ubuntu-drivers detect?
[15:05]  * pitti in a meeting, will lag
[15:05] <cyphermox> yeah getting to it
[15:08] <doko> mvo, https://launchpad.net/ubuntu/+source/aptdaemon/0.45+bzr856-0ubuntu1/+build/3769536
[15:25] <mvo> doko: hello, thanks
[15:31] <m_3> tedg: ping
[15:31] <tedg> m_3, Howdy
[15:47] <mpt> font-family:Ubuntu,'Bitstream Vera Sans','DejaVu Sans',Tahoma,sans-serif;
[15:48] <mpt> ev, any reason you are preferring Vera over DejaVu?
[15:48] <ev> mpt: I probably stole that from qa.ubuntu.com's CSS
[15:48] <ev> so no, no reason
[15:48] <ev> I can quickly swap them around
[16:00] <stgraber> barry: are you aware of any chance in the recent python 2.7 that'd break argparse?
[16:00] <stgraber> barry: arkose stopped working after updateing my quantal system this morning with:
[16:00] <stgraber> AttributeError: 'str' object has no attribute 'append'
[16:00] <barry> stgraber: i'm not
[16:01] <barry> stgraber: bug #?
[16:01] <stgraber> that's when calling args.bind.append() where args.bind is defined as:
[16:01] <stgraber> parser.add_argument("--bind", dest="bind", type=str,
[16:01] <stgraber>     default=[], action='append',
[16:01] <stgraber>     help=_("""Add a bind mount to the container.
[16:01] <stgraber> (allowed multiple times)"""))
[16:01] <stgraber> no bug yet, just got it show up on a few of my machines, will try to get a minimal reproducer
[16:01] <cjwatson> doesn't that want to be type="string"?
[16:02] <stgraber> my guess is that type=str + defaults=[] + action='append' changed from defaulting to an empty list to defaulting to an empty string
[16:02] <cjwatson> oh, argparse not optparse
[16:03] <achiang> micahg: hi, i've updated https://bugs.launchpad.net/ubuntu/+source/wader/+bug/1046102 with a FFe justification... do i need to do anything else, or should i just assume the release team will see it by virtue of them being subscribed?
[16:04] <micahg> achiang: well, it usually goes in the description, but they should see it
[16:04] <barry> stgraber: you should probably just remove the type=str anyway since it's the default
[16:05] <barry> should or could :)
[16:05] <Laney> achiang: incomplete would probably mean that i wouldn't see it
[16:05]  * micahg just fixed that
[16:05] <achiang> Laney: oops, i didn't move the bug state away from incomplete. what should it be?
[16:05] <stgraber> barry: minimal reproducer: http://paste.ubuntu.com/1196908/
[16:05] <Laney> New is good
[16:06] <stgraber> barry: works on older quantal, fails with current
[16:06] <stgraber> barry: regression happens with both python2.7 and python3.2
[16:06] <achiang> micahg: Laney thanks
[16:07] <barry> stgraber: saved me from writing one :)  i just searched the python bug tracker and found nothing relevant
[16:07] <stgraber> barry: FWIW, removing type=str fixes it
[16:08] <ev> mpt: http://bazaar.launchpad.net/~ev/errors/trunk/revision/184 - fixed
[16:08] <barry> stgraber: doesn't fail for me
[16:08] <barry> % python2.7 /tmp/foo.py --test baz
[16:08] <stgraber> barry: call it without the --test
[16:08] <ev> mpt: and live on poppy-dev
[16:08] <stgraber> barry: the problem is the default value
[16:08] <mpt> ev, that's a big spike in Q yesterday
[16:09] <ev> yeah, it's not filling me with confidence
[16:09] <ev> filling in 12.04 now
[16:09] <ev> (still waiting on the RT for the cron job for this)
[16:12] <barry> stgraber: i think this is a misunderstanding of what 'default' does.  it doesn't initialize the dest afaik, but provides the value to use if --test isn't given
[16:13] <barry> stgraber: but hmm
[16:14] <stgraber> barry: my understanding is that when using both action="append" and default=[], args.test should always be a list, either containing what's past on the command line, or an empty one. Having it be an empty string doesn't make any sense.
[16:14] <barry> stgraber: okay, i'm quite confused now.  let me look at upstream and do some code spelunking
[16:16] <stgraber> barry: bug 1048710
[16:16] <stgraber> barry: I filed it against python2.7 as that's where I first noticed it, but as I said here and in the bug, the regression also happens with 3.2
[16:17] <stgraber> for now I just removed the type=str from my local copy of arkose so I can work, I'll probably end up uploading that anyway as it's not required and happens to "fix" the bug...
[16:18] <barry> stgraber: here's what's really weird:
[16:18] <barry> (Pdb) print args.test
[16:18] <barry> []
[16:18] <barry> (Pdb) print type(args.test)
[16:18] <barry> <type 'str'>
[16:18] <barry>  
[16:18] <barry> so args.test is the *string* "[]" :-o
[16:19] <stgraber> oh wow
[16:19] <stgraber> barry: oh, I guess it's basically setting it to type(default) which in this case would be str([])
[16:20] <barry> stgraber: must be, yes.  confirmed in upstream hg head
[16:23] <barry> stgraber: this is probably not relevant, esp. because it's only landed in unreleased 2.7.4:
[16:23] <barry> - Issue #12776,#11839: call argparse type function (specified by add_argument)
[16:23] <barry>   only once. Before, the type function was called twice in the case where the
[16:23] <barry>   default was specified and the argument was given as well.  This was
[16:23] <barry>   especially problematic for the FileType type, as a default file would always
[16:23] <barry>   be opened, even if a file argument was specified on the command line.
[16:23] <barry>  
[16:23] <barry> stgraber: probably worth an upstream bug report because it's either a legit bug or a doco omission
[16:23] <barry> stgraber: i'll file that
[16:23] <stgraber> barry: thanks
[16:25] <barry> stgraber: fwiw, 3.3 seems to dtrt
[16:32] <doko> tkamppeter, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg please could you file MIR's for the new foomatic-db dependencies?
[16:34] <micahg> doko: are we going to have a test rebuild at some point?
[16:35] <barry> stgraber: wtf?!  it "works" in ubuntu's py3.3rc2 but not in upstream hg head.  i bet python issues 12776 and 11839 are somehow involved.  anyway... http://bugs.python.org/issue15906 which i'll link to the ubu bug
[16:37] <doko> micahg, yes, trying to get some mir's addressed first
[17:44] <barry> pitti: ping
[17:44] <barry> mterry: ping too
[17:44] <mterry> barry, hi
[17:45] <barry> pitti, mterry hi.  lp #887699 - i never got to this one.  i'm afraid we may not have time for quantal.  i don't know what it's blocking, and whether it's worth still trying to attack for quantal.  i'm also not sure how much work it is
[17:46] <mterry> barry, it's OK.  I assumed you weren't getting to it at this point.  The deal is that it's blocking Quickly from supporting Python 3 projects that users want to create (and we want to recommend them creating)
[17:47] <mterry> barry, we can coast another release with only supporting python2 projects, but it should probably happen for 13.04, since we are getting out of step with what we ourselves recommend (python3) and what we are forced to recommend to app authors (python2)
[17:47] <mterry> barry, though, in 13.04, we are looking at using pkgme instead, so maybe that bug becomes irrelevant?
[17:47] <barry> mterry: okay.  i'll target it to 13.04 and bump the priority to high.  i'm working on the new blueprint for rocky raccoon
[17:48] <infinity> We certainly want those two things to be well-tested and in lockstep by the next LTS, so the earlier, the better.
[17:48] <barry> mterry: +1 for pkgme!
[17:48] <micahg> any hope of only needing python3 by the next LTS?
[17:49] <infinity> micahg: Define "need".
[17:49] <micahg> images :)
[17:49] <barry> micahg: not archive-wide but hopefully yes for ubuntu-desktop task and main (if there is a main <wink>)
[17:49] <infinity> micahg: There's zero hope of everything in universe being ported to python2, but ubuntu-desktop, for sure.
[17:49] <micahg> infinity: xubuntu desktop is on my mind ATM :)
[17:49] <infinity> micahg: And it would be nice if the other -desktops could get there too.
[17:52] <barry> i feel confident about twisted, not so confident about xapian, ecstatic that we can ignore launchpadlib stack, and worried about all the canonical-led projects. :)
[17:55] <trism> Anyone working on a new upload of gnome-control-center? I added a debdiff with the upstream commit that fixes the pretty nasty bug 1041756 (don't know if anyone noticed the bug, been undecided since august)
[18:03] <infinity> bdmurray: Did you want to fix #1038302 and supersede the current SRU in the queue?
[18:04] <bdmurray> infinity: yeah, I guess.
[18:04] <infinity> bdmurray: Doesn't make much sense to do them one at a time, IMO.
[18:05] <bdmurray> infinity: I'd mentioned that in the other bug
[18:05] <infinity> bdmurray: Yeah, I figured since you fixed it in Q, you might just do the P fix as well. :P
[18:06] <infinity> bdmurray: If you'd like to grab the sources from the queue and just add your changes to it (you can reuse the version, I'll just reject the old one)
[18:06] <bdmurray> infinity: okay, after lunch then
[18:26] <ScottK> tjaalton: Would you please have a look at the last several comments in Bug #956071 and let me know if you think that's the fix is incomplete/there are other bugs or there's a regression in this update?
[18:27] <infinity> ScottK: Yeah, looked incomplete to me too.  I was about to give it a regression tag.
[18:28] <infinity> ScottK: It's hard to say if it's actually a regression or an incomplete fix, but the result of "some touchpads stop working" seems suboptimal.
[18:28] <ScottK> infinity: I wasn't sure if it's 'not fixed, but better' or 'better for some/worse for others.'
[18:28] <ScottK> True.
[18:32] <tjaalton> ScottK: looks weird.. works perfectly on my t420s on precise
[18:32] <tjaalton> but I'll reopen it then
[18:32] <infinity> I tagged it and added a comment.  Would be nice if we could get some slightly less contradictory results. :/
[18:32] <ScottK> Yes.
[18:33] <infinity> If someone could walk someone through reproducers with $old and $new and make sure it was being done sanely, that would be lovely.
[18:33] <infinity> (And by "someone", I mean "someone who claims it's still broken")
[18:33] <tjaalton> I'll do that tomorrow
[18:33] <tjaalton> didn't test hotkeys
[18:34] <infinity> Thanks.
[18:37] <tjaalton> heck, testing it now. and seeing that there's a cool icon popup when hitting the hotkey :)
[18:38] <tjaalton> that was quick, needs only two cycles
[18:38] <infinity> pitti: Can you grab the current ntfs-3g from -proposed, rebase your upload against it, and reupload with a -v to get both in the changes?
[18:39] <infinity> pitti: (Didn't notice the two conflicting uploads before I accepted one..)
[18:51] <tjaalton> infinity: hotkeys fail to enable it with the old version too
[18:52] <tjaalton> the testcase was bad :)
[18:52] <tjaalton> should've put xinput disable/enable there
[18:52] <tjaalton> that works just fine
[18:52] <tjaalton> it's still a bug, dunno about the other reports what they're seeing
[18:54] <infinity> tjaalton: I don't want to know the answer to "why don't the hotkeys just call into the same codepath at xinput", do I?
[18:54] <infinity> s/at/as/
[18:57] <tjaalton> infinity: right, no idea why not..
[18:57] <tjaalton> I'll check that tomorrow, updated the bug with my findings
[19:00] <infinity> Thanks
[19:31] <bdmurray> infinity: feel free to reject the old trousers
[19:33] <infinity> bdmurray: Done.
[20:11] <infinity> bdmurray: Erm.
[20:11] <infinity> bdmurray: If I'm reading that diff right, the precise version didn't HAVE a prerm at all (broken or otherwise) until it was just now added...
[20:14] <infinity> bdmurray: Yeah, grabbing the current binaries confirm that.
[20:14] <infinity> bdmurray: So, I'm going to reject this, invalidate the precise task, and accept the old upload. :P
[20:17] <infinity> bdmurray: I guess I could have checked that instead of taking your word for it in the bug trail.
[20:40] <doko> Daviey, zul: horizon pulls in a bunch of packages into main, although MIR's are missing
[20:40] <zul> doko: lessc?
[20:41] <doko> zul, yes, less.js, see http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[20:41] <zul> doko: ack
[20:46] <doko> jamespage, ceph pulls xml2 into main, which is missing a MIR
[20:47] <Daviey> doko: horizon is known. It should not have a MIR, as it is pending being dropped
[20:47] <Daviey> It's not a current blocker for cdimages, as it isn't on the cd, nor a build dep
[20:47] <doko> just trying to clear component mismatches
[20:48] <Daviey> doko: I'm not ignoring it either :)
[21:07] <dobey> the langpack stuff will use translations from the upstream source, if the strings are not yet translated directly in ubuntu, right?
[21:12] <doko> pitti, cjwatson: ibus-m17n was demoted in 2010, according to the seeds bzr log. however it's now (again?) in supported.
[21:13] <doko> without a MIR
[21:19] <doko> roaksoax, Daviey: the MIR's for celery and raphael were incomplete. I did open new tasks and assigned these to roaksoax
[21:21] <roaksoax> doko: ok thanks will take a look at them